A block groups transactions and related data under a network’s rules. Links between blocks support an ordered history, while validation and consensus determine which history is accepted.
A block is a structured group of transactions and related information used by a blockchain protocol. Its precise contents depend on the network. Understanding blocks helps distinguish a submitted transaction from one included in the network’s accepted history.
What a Block Contains
A block commonly contains transaction data and a header with information needed to place and verify it. The header links it to an earlier block through a cryptographic reference. Networks can include additional fields that reflect their execution and consensus designs.
A block’s identifier and its height are different. The identifier distinguishes a particular block, while height describes its position in a branch of history. Competing blocks can exist at the same height before the network resolves which branch to follow.
From Submission to Inclusion
A transaction passes through several stages before it becomes an established part of the ledger. The visible wallet status should be interpreted in that context.
Building a Candidate Block
A producer assembles candidate transactions according to the protocol and its own selection process. The existence of a pending transaction does not guarantee immediate inclusion. It must satisfy validity rules and compete for available processing capacity.
Capacity can be limited by size, weight, computation or other protocol measures. Different transactions can consume different amounts of capacity. A block’s transaction count alone therefore does not describe its full workload.
Cryptographic references connect blocks; validation checks the records they contain.
Linking the History
A block references its predecessor, which in turn references earlier history. Changing earlier content alters the relevant cryptographic commitments. That makes a modified history detectable, but the links alone do not determine which competing history a network accepts.
Consensus rules supply that additional decision process. They differ between networks, so a claim about a block’s permanence must be interpreted under the relevant finality model rather than treated as an automatic property of any linked data structure.
Why Validation Matters
Participants check blocks against protocol rules instead of trusting a producer’s assertion that the contents are correct. Those checks help prevent invalid state changes from being accepted.
The specific rules can cover signatures, available funds, transaction structure and execution results. A block producer cannot make a transaction valid simply by placing it in a proposed block. Independent validation is a distinct role from producing the proposal.
How Block Production Differs
Networks choose different mechanisms for proposing blocks and resolving competing proposals. Proof of work and proof of stake are two examples, with different resources and security assumptions.
Proof-of-Work Production
In Bitcoin, miners search for a block-header hash that meets the required target. Successful work supports a candidate block, which still has to pass the network’s validity checks. Competing valid histories are assessed by accumulated proof of work.
Rewards and transaction fees are governed by protocol rules. They provide part of the incentive for production, but receiving a proposed block reward is not the same as having an invalid block accepted by other nodes.
Checking and Accepting a Block
In a proof-of-stake system such as Ethereum, proposal and voting rules use a different mechanism. Participants still check execution and consensus conditions. The exact steps and finality criteria should be read from that network’s current documentation.
Capacity and Processing Time
Block interval and capacity influence transaction processing, but do not alone determine the user’s total waiting time. Submission, inclusion, finality and application crediting can add distinct stages to the experience.
Block timing, transaction inclusion and application availability are separate stages.
Why a Transaction May Wait
A transaction can remain pending because of available capacity, fee conditions, dependencies or the producer’s selection. It can also fail validity checks or be dropped by the systems holding it. Do not assume that every pending transaction must appear in the next block.
Reading an Accepted History
An explorer can show where a transaction was included and the blocks that followed. That evidence helps interpret confirmation depth or finality, depending on the network. A receiving application may require an additional policy threshold before crediting a deposit.
Recent history can change under some consensus conditions, while other systems define explicit finality rules. Describe the actual network stage rather than calling every newly included transaction irreversible. DTCC Trading’s glossary explains the concept without certifying a particular network’s security.
Related Concepts
FAQs about Block
Do all networks create blocks at the same interval?
No. Timing depends on the protocol, and observed intervals can differ from a nominal schedule or target. A block interval also does not equal the full time required for a particular transaction to be submitted, included, finalized and credited by an application.
