Blocks

A block is not merely a folder of transactions. It contains protocol metadata that lets nodes verify where the block belongs, whether its contents are valid, and whether it satisfies consensus requirements. In Bitcoin, the block header includes a version, previous-block hash, Merkle root, timestamp, difficulty target representation, and nonce, while the block body contains transactions.

Other blockchains use different fields, but the underlying function is similar: commit to an ordered batch and connect it to accepted history.

The previous-block hash links the new block to its parent. The Merkle root summarizes all transactions in the block through a tree of hashes. Consensus-specific fields carry evidence such as proof-of-work parameters or validator-related data. The transaction list contains the state-changing operations that nodes must validate.

A node can therefore check both the internal integrity of the block and its relationship to prior history.

When a node receives a block, it checks the header, parent relationship, consensus conditions, block-format limits, and every transaction. It recomputes transaction commitments such as the Merkle root and verifies that applying the transactions to the prior valid state produces a valid next state. A single invalid transaction can make the entire block unacceptable.

Validation is deterministic under the protocol: nodes do not vote on whether an invalid transaction should be forgiven.

Larger blocks can include more transaction data, but they also take longer to transmit, validate, and store. If propagation takes too long, different block producers can work on competing views for longer, increasing stale or orphaned work in systems where simultaneous production is possible. Smaller blocks reduce per-block resource load but can constrain transaction throughput.

Protocols therefore choose capacity, timing, and execution limits as part of a broader network-design trade-off rather than maximizing one metric in isolation.

A useful way to reason about a block is to separate three questions: what data it carries, what it commits to, and what makes it acceptable. The body usually contains transactions or other protocol payloads. The header carries compact metadata that lets nodes connect this batch of activity to prior history and verify protocol-specific constraints. A previous-block reference ties the new block to a parent, while a transaction commitment such as a Merkle root lets the header stand for many individual records without copying all of them into the header itself.

Validation happens at more than one level. A node can reject a block because its header violates consensus rules, because one or more included transactions are invalid, because the resulting state transition is invalid, or because the block exceeds a protocol resource limit. Passing one test does not guarantee passing the others.

Block design also creates system trade-offs. Larger or more frequent blocks may increase raw transaction capacity, but they also increase propagation, bandwidth, validation, and storage demands. If some nodes receive a new block much later than others, the network spends more time with different views of the latest chain tip. That can affect fork frequency and decentralization because slower nodes face a larger disadvantage. For this reason, block parameters are part of the security and networking design, not merely a file-format choice.

1. Distinguish a block header from a block body and give one example of information commonly found in each.

2. Why can a block have a valid-looking header yet still be rejected by a full node?

3. Explain how a previous-block hash connects a new block to chain history.

4. Why does a transaction commitment such as a Merkle root allow compact verification without placing every transaction directly in the header?

5. Describe one throughput benefit and two network costs of increasing block capacity.

6. Correct this statement: “Once a producer creates a block, every honest node must accept it.”