What Are Blocks in Blockchain and How They Work
You send Bitcoin or Ethereum, see the transaction marked as pending, and start wondering what the network is doing. Your wallet has broadcast the request, but the recipient hasn't received a final settlement yet. The missing step is a block, the package that records activity, fixes its order, and gives the network something concrete to verify.
Understanding what are blocks in blockchain means understanding more than where transactions are stored. A block is also a cryptographic state transition. It connects a new version of the ledger to its predecessor, gives consensus participants a shared ordering, and creates the confirmations that users rely on before treating a payment as settled.
The idea applies across Bitcoin, Ethereum, DeFi, Web3 applications, smart contracts, token transfers, Layer 2 networks, and real-world asset tokenization. The details vary by chain, but the practical questions remain familiar. Who creates the block? Which transactions get included? Why do fees rise during congestion? How quickly does the block reach other nodes? How certain is the transaction after inclusion?
This guide starts with the basic ledger model, then moves inside a block's header and transaction body. It follows the lifecycle from a pending transaction to consensus, propagation, and finality, before examining the metrics that shape throughput and user experience. You'll also learn how to inspect these details directly with a blockchain explorer. For broader context, you can review these blockchain technology basics first.
Table of Contents
- Introduction to What Blocks Mean in Blockchain
- What Are Blocks and Why They Form a Chain
- Inside a Block Header Transactions and Merkle Root
- How Blocks Are Created and Validated Through Consensus
- Block Propagation Finality and Network Security
- Key Block Metrics Every Crypto User Should Know
- How to Inspect Blocks Using a Blockchain Explorer
Introduction to What Blocks Mean in Blockchain
A blockchain transaction doesn't become settled because a wallet has signed it. The network must receive the transaction, check its rules, place it alongside other valid activity, and agree on the resulting ledger state. A block is the structure that brings those steps together.
Bitcoin offers the clearest foundational example. Its network launched with the genesis block on January 3, 2009, and its design targets a new block roughly every 10 minutes, as documented in this Bitcoin block timing analysis. That interval is the network's operating rhythm. Transactions wait for block space, a miner proposes a candidate block, and nodes decide whether the candidate follows the protocol.
The rhythm isn't perfectly regular. One statistical review measured an average interval of about 587 seconds, or 9 minutes 47 seconds, from the genesis block through block 762150, while another dataset covering more than 725,000 blocks found an average of about 9.8 minutes and a median of 6.9 minutes. These figures explain why a transaction can't be treated like an instant database update. Block production depends on consensus, and consensus needs time to coordinate independent participants.
A block therefore affects several outcomes that users notice directly:
- Confirmation time: A transaction generally needs to be included in a block before the network treats it as recorded.
- Fees: Block space is limited, so users may compete for inclusion when pending demand rises.
- Ordering: The block establishes where a transaction sits relative to other transactions.
- Security: Later blocks strengthen the history that contains the transaction.
- Trust: Nodes can verify the result without relying on a single company's server.
Practical rule: A wallet's “sent” status means the transaction was broadcast. A block inclusion means the network has recorded it, subject to the chain's finality model.
The key mental shift is simple. A block isn't just a container waiting to be filled. It's an agreed update to a shared state, and that update determines when balances change, smart contracts execute, and settlement becomes harder to reverse.
What Are Blocks and Why They Form a Chain
Start with a shared notebook. Each page contains a batch of approved entries, and every new page includes a fingerprint of the page before it. If someone changes an old entry, that page's fingerprint changes, so the later pages no longer point to the correct history.
That's the basic logic behind a blockchain block. A block typically groups validated transactions and links to its parent through a cryptographic hash, creating a sequence that nodes can check. Ethereum describes blocks as batches of transactions that include the previous block's hash. Changing one block would invalidate the hashes that follow it, as explained in the Ethereum block documentation.
The container is only the starting point
A block's container role is easy to understand. Bitcoin blocks bundle payments. Ethereum blocks can include transfers, smart contract calls, and other execution activity. A Layer 2 block may organize batches of activity that are later committed to another blockchain. The contents differ, but the block gives the network a bounded set of actions to validate.
The more important role is state transition. A transaction changes the ledger state, such as moving tokens, updating a smart contract, or consuming an unspent output. The block groups those changes, assigns them an order, and commits them to a specific parent. Nodes can then calculate the resulting state and compare their validation results.
Ordering matters because transactions can interact. A decentralized exchange trade, collateral update in DeFi, or contract call may produce a different result depending on which action executes first. The block provides the ordering context that turns a collection of requests into an agreed sequence of state changes.
Why the chain matters
The previous-block hash creates continuity. Each block points backward, while the network's consensus rules determine which candidate is accepted as the next extension. If two valid candidates appear at nearly the same time, nodes may temporarily disagree about the tip. That temporary disagreement is a fork. When the network later converges on one history, the discarded branch represents a reorganization, often called a reorg.
A reorg demonstrates why blocks are more than permanent-looking pages. Inclusion is a meaningful event, but some chains provide stronger assurance only after additional blocks or consensus checkpoints. Finality can be probabilistic in major networks, so confirmation risk depends on the chain's design and the depth of the transaction in its history.
Inside a Block Header Transactions and Merkle Root
A block usually has two major parts, the header and the body. The body carries the transaction list. The header carries compact metadata that identifies the block, connects it to the chain, and helps nodes verify its production and contents.
The header's verification fields
The previous block hash is the parent fingerprint. It tells nodes which earlier block this candidate extends. If the candidate names a different parent, it belongs to another possible branch.
The timestamp records the block's claimed creation time. Nodes don't treat that field as unquestionable proof of real-world time, but they use it within the protocol's validation rules.
The nonce is a value miners vary while searching for a proof-of-work solution. Miners repeatedly alter candidate header data and calculate hashes until the result satisfies the network's difficulty requirement.
The difficulty target defines how demanding that proof-of-work condition is. It helps the network regulate block production even as the amount of mining hardware and hash power changes.
The Merkle root, or an equivalent transaction-commitment field, summarizes the transactions in the body. A Merkle tree combines transaction hashes into a single root hash. If a transaction changes, the resulting root changes, giving nodes an efficient integrity check without requiring them to treat a central server as trustworthy.
A useful way to read the header is as a compact declaration: this block follows that parent, was produced under these consensus conditions, claims this time, and commits to this exact transaction set.
The body and its transaction list
The body contains the transactions selected for inclusion. Each transaction still needs to satisfy the chain's rules, including valid signatures, available funds or inputs, and any execution requirements. The header doesn't replace those checks. It gives the network a concise commitment to the collection that the body presents.
Bitcoin's genesis block offers a memorable example of why block inspection can be useful. The Bitcoin genesis block guide explains how readers can use a block explorer to find block height 0, inspect its hash and coinbase transaction, and view the newspaper text embedded in Block 0.
Ethereum and other execution-focused networks extend the idea beyond simple payment records. Their blocks can commit to contract execution, token balances, receipts, and other state-related information. The exact fields vary, but the principle stays consistent. Nodes use cryptographic commitments and protocol rules to establish what happened and whether the proposed state transition is valid.
How Blocks Are Created and Validated Through Consensus
A block begins with transactions that haven't yet been included. Users sign those transactions and broadcast them to the network. Nodes check basic validity and place acceptable requests in a mempool, a waiting area rather than a permanent ledger.
From pending requests to a candidate block
A block builder selects transactions and assembles a candidate. Selection isn't always first come, first served. On fee-driven networks, builders often prioritize transactions according to fee incentives and the available block space. Ethereum's execution environment adds another layer, because smart contract calls consume computational resources and may interact with one another.
In DeFi, transaction ordering can affect trade execution, liquidations, and arbitrage opportunities. The broader topic is often called MEV, or maximal extractable value. It matters because the person or system constructing a block may have economic reasons to choose one ordering over another, subject to the chain's rules and the transaction fees offered.
Bitcoin uses proof of work. Miners compete to find a valid block header by varying values such as the nonce and repeatedly hashing the candidate. The successful miner broadcasts the block, but winning the computational race doesn't make the block automatically valid. Other nodes still check its transactions, header, proof, and relationship to the current chain.
Ethereum uses proof of stake. A designated block proposer creates a candidate, while other participating validators attest to whether it follows the protocol. This changes who performs the production work, but the network still requires independent validation before accepting the state transition.
Why block space creates user-visible pressure
Every chain places limits on the work or data that a block can carry. When pending demand approaches those limits, users may experience higher fees, slower inclusion, or both. Layer 2 networks address some scaling pressure by processing activity in specialized environments and committing relevant data or results to another chain, though users still need to understand the settlement and withdrawal assumptions involved.
A block builder also has to balance capacity against distribution. Bigger or more complex blocks may carry more activity, but they can take longer to transmit and validate. That trade-off links consensus design to ordinary user experiences such as a delayed swap, a higher gas fee, or a payment that remains pending.
The lifecycle can be reduced to five practical stages:
- Mempool: Nodes receive and screen pending transactions.
- Block building: A miner, validator, or specialized builder selects activity and constructs a candidate.
- Consensus: Proof-of-work miners compete, or proof-of-stake participants propose and attest.
- Validation: Nodes verify the block's structure, transactions, signatures, and consensus requirements.
- Inclusion: The accepted block extends the chain and is relayed to other participants.
Block Propagation Finality and Network Security
A valid block only helps the network after other nodes receive and verify it. Propagation is the process of relaying that block across the distributed network. Speed matters because two miners or proposers can produce competing candidates before everyone has seen the same update.
Research summarized by the Bitcoin block propagation tracker reports that median relay time improved from over 6 seconds in 2015 to under 1 second by 2018. The same source records a decline in the 90th percentile from over 15 seconds to about 2 seconds during that period.
Faster relay reduces the time during which different parts of the network see different chain tips. It also lowers the chance that a miner wastes work on a block that another branch has already displaced. Bitcoin's early years saw 1% to 2% of blocks become stale, while the tracker records 60 stale blocks in 2017, 5 in 2018, and 2 in 2019. Those figures show how network engineering can improve the practical efficiency of consensus.
Stale blocks and temporary disagreement
A stale block is a valid block that doesn't remain part of the selected main history. People sometimes use “orphan” loosely for the same situation, although technical usage can distinguish different causes. The user impact is important either way. A transaction included in a branch that later loses a reorganization may need to be included again.
Compact block relay became the default in Bitcoin Core in 2016, helping modern blocks reach over half of the network in under 1 second and over 90% of nodes within 2 to 6 seconds, according to the same tracker. The goal isn't cosmetic speed. Rapid delivery helps nodes converge on one view of the ledger and reduces competing block production.
Confirmation is not always finality
A confirmation means a transaction appears in an accepted block. Additional blocks add depth behind it, making a reversal more difficult on probabilistic-finality networks. That doesn't create an absolute guarantee in every system, but it changes the amount of history an attacker or competing branch would need to overcome.
Some networks use stronger deterministic finality mechanisms, while others rely on economic or computational weight accumulating over time. Users should therefore check the specific chain's confirmation and finality conventions instead of treating the word “confirmed” as identical across Bitcoin, Ethereum, and Layer 2 systems.
Key Block Metrics Every Crypto User Should Know
Block metrics translate protocol design into outcomes you can feel in a wallet or application. Block size, block interval, transaction capacity, execution limits, and throughput interact. Looking at one metric alone can create a misleading comparison between Bitcoin, Ethereum, and Layer 2 networks.
| Metric | What It Measures | Why It Matters to Users |
|---|---|---|
| Block size or weight | The data or weighted capacity available in a block | Determines how much activity can fit, while larger blocks may take longer to propagate |
| Block interval | The time between successive blocks | Influences how quickly pending transactions get an inclusion opportunity |
| Transaction count | The number of transactions bundled into a block | Shows how activity is packaged, but doesn't capture the complexity of each transaction |
| Gas or execution limit | The computation and execution work a block can process | Affects smart contract capacity, application complexity, and fee pressure |
| Throughput | Transactions processed over time | Helps compare practical capacity, but should be considered alongside latency and propagation |
| Confirmations | Accepted blocks built after the transaction's block | Indicates how much additional chain history supports the transaction |
Capacity has a network cost
Blockchain performance research defines block size as the maximum number of transactions or bytes in a block, and block interval as the time between successive blocks. A basic throughput approximation divides transactions per block by the time between blocks. That calculation is useful, but it doesn't capture the full network trade-off.
Increasing block size can raise raw capacity. It can also increase propagation delay, and if nodes receive blocks too slowly, the network may lose some of the expected efficiency. A classic scaling analysis found that, under a 10-minute block interval, Bitcoin-like networks should keep block size around 4 MB to maintain roughly 90% effective throughput, corresponding to an upper bound near 27 transactions per second. Beyond that point, propagation delay becomes the limiting factor rather than raw block capacity, according to this blockchain performance analysis.
Bitcoin's post-SegWit capacity isn't a fixed 1 MB. It's measured in 4 million weight units, which typically translates to roughly 1.5 to 2.3 MB in practice. Recent market data cited by the Bitcoin block size explanation places average Bitcoin block sizes around 1.6 MB in 2026. Real usage can remain below the theoretical maximum because transaction demand and transaction composition change over time.
For users, the practical lesson is to compare the whole system. A chain may advertise high capacity, yet still face execution, propagation, decentralization, or settlement constraints. Layer 2 networks may offer a different balance, with faster application-level activity but separate assumptions about data availability and final settlement.
How to Inspect Blocks Using a Blockchain Explorer
A blockchain explorer turns the abstract block model into something you can verify. You can search by transaction ID, block height, or block hash, then inspect the relationship between the transaction and the chain that recorded it.
A practical inspection workflow
Open a chain-specific explorer. Use a Bitcoin explorer for Bitcoin transactions and an Ethereum explorer for Ethereum activity. Layer 2 networks generally have their own explorers, and their confirmation labels may not mean the same thing as settlement on the underlying chain.
Search for the transaction hash. The transaction page should show whether the request is pending, confirmed, failed, or otherwise unresolved. Check the destination address, amount, fee, and transaction type carefully.
Find the containing block. Once included, the page should identify the block height and hash. Open the block to inspect its timestamp, transaction count, parent reference, and other available metadata.
Review confirmations. The explorer may display how many later blocks have been added. More confirmations generally provide stronger support on probabilistic-finality chains, but the acceptable threshold depends on the asset, service, and network risk policy.
Investigate unusual status changes. A pending transaction may be waiting for fee-based selection or network handling. A transaction that disappears from a recent block after a reorganization may need further review. On Ethereum, a failed contract transaction can still consume a fee even though the intended state change didn't complete.
The blockchain explorer guide provides a broader introduction to searching transactions and reading on-chain records. Explorers are useful evidence, but they don't eliminate market volatility, smart contract risk, bridge risk, custody risk, or the possibility of confusing a Layer 2 confirmation with final settlement on its base layer.
Use current explorer data before making decisions, especially when fees, network conditions, or protocol rules may have changed. This article is educational information, not personalized financial advice.
Coiner Blog publishes practical guides on Bitcoin, Ethereum, blockchain mechanics, DeFi, Web3, Layer 2 networks, and other digital asset topics. Visit Coiner Blog to keep building the technical knowledge needed to verify transactions, understand network trade-offs, and evaluate crypto developments with a more informed perspective.