Blocks, hashes and the chain

From individual transactions to blocks

A blockchain normally does not ask every node to agree on each transaction as a completely separate permanent record. Instead, transactions are organized into batches called blocks, with rules describing how blocks are proposed, checked, and connected. A block is not just a page in an electronic ledger. It is a protocol-defined data structure that contains or commits to transactions and carries information used to link the block to preceding history. The exact fields differ among systems. Some protocols separate execution data and consensus data; others use a comparatively compact block header with transactions following it.

To understand the chain, distinguish transaction content, a summary commitment, and a pointer to earlier history. A transaction describes a requested change in ledger state. A cryptographic hash is a fixed-length output produced from input data by a defined algorithm. A block can include a hash or related commitment to the transaction set; its header generally refers to a predecessor using a hash. Linking records this way makes an unannounced alteration detectable because altered data changes the relevant commitment with overwhelming probability under the hash function's security assumptions.

What a cryptographic hash does

A cryptographic hash function converts information of arbitrary length into a digest of a fixed size. For example, SHA-256 generates a 256-bit digest. SHA-256 is specified in the National Institute of Standards and Technology's FIPS 180-4, Secure Hash Standard. The digest is not encryption: it does not contain a secret that can be unlocked to recover the original input. A hash also does not certify who created a document. It is useful for comparing information and detecting changes, subject to proper implementation and an appropriate algorithm. More specialized algorithms and combinations are used by different blockchains.

A good cryptographic hash is designed so that it is computationally infeasible to find a different message that produces the same digest, or to work backward from the digest to a selected original message. These are security properties, not absolute mathematical impossibilities. If the input changes even slightly, its digest will usually look entirely different. Therefore a node that knows the correct commitment can detect that a block body has been replaced or edited. This detection does not on its own identify the person responsible for the change, and it does not prove that the original content was accurate.

A hash pointer is more than an ordinary link

A conventional database pointer says where to find another record. A hash pointer combines a reference to a previous record with a value that commits to its expected content. Consider blocks A, B, and C. Block B records a hash referring to A; C refers to B. If someone edits A, the digest that B expects no longer matches. Fixing B's reference changes B and then breaks C's reference. This dependency extends along subsequent blocks. In real protocols, an attacker wishing to replace accepted history must also satisfy the applicable consensus rules, not merely recompute hashes.

Headers, bodies and transaction commitments

Many block designs have a header containing compact metadata and a body with transactions or other execution information. In Bitcoin, the header includes a previous-block hash, a Merkle root summarizing transactions, a timestamp, a difficulty target encoding, a version, and a nonce. A nonce is a field that can be varied while seeking a qualifying proof of work. This field list is an example, not a universal blockchain requirement. Modern systems can use different commitment trees, signatures, validator attestations, or separate payload structures.

A Merkle tree summarizes a collection of records using a hierarchy of hashes. Leaf values commit to individual elements; intermediate values commit to combinations of elements; the top value is called the Merkle root. This structure can support an inclusion proof: a compact set of hashes demonstrating that a particular element belongs to the collection committed by the root. Inclusion proofs help reduce the amount of data needed for some verification tasks, but they do not replace all of the checks performed by a full node, such as checking whether the transaction was authorized and whether a conflicting spend exists.

Order and serialization are protocol rules

A node cannot hash a vague description such as 'Alice paid Bob.' It must hash a precise sequence of bytes in a specified format. This is serialization: representing structured information as bytes according to published rules. Field order, number encoding, and other details matter. If two nodes serialize the same conceptual record differently, their hashes can differ. Consensus therefore depends on more than strong cryptography; it also needs deterministic definitions of valid encoding, transaction ordering where applicable, block limits, and the state changes each transaction produces.

Tamper evidence versus immutability

It is common to describe blockchains as immutable. For an introductory course, tamper-evident and tamper-resistant are more precise. Hash links expose unauthorized modifications to a recorded chain, while consensus mechanisms make replacement of accepted history difficult under stated assumptions. Neither feature makes history metaphysically impossible to change. Forks, reorganizations, protocol upgrades, and failures of a network's security assumptions can all affect which chain is accepted. Legal records also may require amendments; a system can preserve prior entries while appending corrective entries without secretly overwriting them.

An important design question is what is stored on-chain. Storing a hash commitment to an off-chain document can let reviewers later check whether the same document was presented. It does not mean the document itself is available on the blockchain, and a hash alone may not supply legally sufficient evidence of authorship, identity, or consent. For public-sector uses, retention requirements, sensitive data, and availability of source records may matter more than the elegance of the commitment structure. Hashes are valuable building blocks, but institutional records management requires additional controls.

How nodes verify a proposed block

A node receiving a candidate block generally performs multiple layers of checking. It evaluates basic data structure and encoding, checks the predecessor reference, verifies that the required consensus evidence is present, and tests transactions against the protocol's state-transition rules. In a network with proof of work, it also checks the header's proof against a target. In a proof-of-stake network, it may check the proposer authorization and relevant votes or attestations. These operations have precise specifications in each protocol; merely seeing a valid-looking hash is never sufficient to declare a block acceptable.

The predecessor requirement also explains why downloading a block in isolation is not the same as establishing a trustworthy ledger state. Validation relies on context: preceding rules, balances or unspent outputs, and the chain selected by the network. A light client may obtain inclusion evidence without independently executing all transactions; that convenience can involve different trust assumptions. Managers and auditors should distinguish a claim that 'this transaction appeared in a block' from a claim that 'a fully validated network history accepts this transfer.' The latter requires additional context and a defined confirmation policy.

Governance and disclosure context

Technical structure is one part of broader system documentation. ISO 23257:2022 describes functional components and relationships for distributed ledger systems. Disclosure rules in some jurisdictions (for example, the EU's crypto-asset white paper requirements) ask issuers to describe the underlying technology, but such obligations do not prescribe one universal block structure or make any particular hash algorithm safe. This illustrates why a technical description and a legal disclosure answer different questions: the former states how a protocol works; the latter determines what information must be communicated in a regulated context.

Quick reference

What learners should retain

Blocks are structured batches or commitments governed by protocol rules. Cryptographic hashes create compact fingerprints and link dependent history; they detect changes but do not establish identity or factual truth. Strong hash functions, deterministic serialization, full validation, and a consensus mechanism work together. The next lesson examines one way a network makes changing the accepted chain costly: proof of work. Keys and digital signatures are explored separately in Module 3.

Exam focus: Identify the roles of a block header, a cryptographic hash, a predecessor reference, and a transaction commitment; explain why hash links provide tamper evidence rather than unconditional immutability.

Source notes

Relevant references: NIST FIPS 180-4 (2015), Secure Hash Standard; NIST IR 8202 (2018), Blockchain Technology Overview; ISO 23257:2022, Reference architecture.