Anatomy of a blockchain

An identity card of 80 bytes

A block is made of a header (small, fixed size in Bitcoin) and a body (the list of transactions). The header summarises the block and links it to the chain. Let us start with Bitcoin, whose format is the simplest: the header is exactly 80 bytes.

The 4-byte integers are little-endian: the least significant byte comes first. The block hash is SHA-256 applied twice to those 80 bytes. In Bitcoin, explorers display this result with the bytes in reversed order; the "internal" order is the one used in the computation.

Reading fields by hand

Version: the bytes 00 00 00 20 read little-endian give the integer 0x20000000, which is 536,870,912 in decimal.

Timestamp: the bytes 00 3c 9a 65 give 0x659a3c00 = 1,704,606,720 seconds, that is 7 January 2024 at 05:52:00 UTC. (An example value chosen for the exercise, unrelated to any specific block.)

Nonce: the bytes 2a 00 00 00 give 0x2a = 42.

The bytes tool below does these readings for you: paste hexadecimal, slice ranges, read little- or big-endian, reverse the order.

The "bits" field: the target in compact form

The 4 bytes ff ff 00 1d read 0x1d00ffff. The most significant byte, 0x1d = 29, is the exponent; the next three, 0x00ffff, are the mantissa. The target is mantissa × 256^(exponent − 3), here 0xffff × 256^26. A block hash, read as a big number, must be less than or equal to the target. A smaller target requires more leading zeros in the displayed hash: that is the difficulty.

And elsewhere?

Not every network has this header. An Ethereum header contains, among others, the parent hash, a state root, a transactions root, a receipts root, a block number, a timestamp and fee-related fields. A CometBFT header contains, among others, the previous block's identifier, the hash of the validator set and an app_hash field that commits to the application state. Names and sizes change; the idea stays the same: a small object that commits to everything else.

What this does NOT guarantee

• The timestamp is claimed by the miner: it is constrained by tolerance rules, but it is not an exact clock.
• The version field does not prove a miner really applies the rules it announces.
• A low block hash proves work was done, not that the body's transactions are valid.

Recap

The header is a commitment of 80 bytes (in Bitcoin): parent, summary of the transactions, difficulty, nonce. Its double SHA-256 is the block's identity.

Where does a transaction go after "Send"?

Awa sends 50 units to Bineta from her phone. Nothing is "sent" to Bineta: the signed transaction is broadcast across a peer-to-peer network. Let us follow it.

1. Creation and signing. The wallet builds the transaction (recipient, amount, fee, nonce) and signs it with Awa's private key (workshop 105).
2. Broadcast. The wallet hands it to a node, which relays it to its peers by gossip: each one forwards it to its neighbours.
3. Local validation. Each node checks, according to its network's rules, the signature, the format, the balance or inputs, the nonce (in account models) and the fee before keeping or relaying it. An invalid transaction is dropped.
4. Mempool. Valid but unconfirmed transactions wait in the node's mempool ("memory pool", the waiting queue). There is no global mempool: every node has its own, which may differ slightly from its neighbour's depending on what it received and its own rules.
5. Selection. The next block's proposer picks transactions from its mempool, usually the ones paying best per unit of space, within the block size limit.
6. Block and propagation. It builds the block, computes the Merkle root of the transactions, fills in the header, does what its consensus requires (hash lottery or vote), then broadcasts the block.
7. Block validation. Every full node replays the block: valid header, known parent, every transaction valid.
8. Confirmation then finality. The block becomes the chain's tip; afterwards, depending on the family (workshop 109), it gains confirmations or is finalised.

Worked example

A block has room for 4 transactions (made-up figure). A proposer's mempool holds: T1 fee 2, T2 fee 9, T3 fee 5, T4 fee 1, T5 fee 7, T6 fee 4. It fills the block by decreasing fee: T2 (9), T5 (7), T3 (5), T6 (4). T1 and T4 wait for the next block. If Awa had set a fee of 1, her transaction could wait a long time: fees are the price of access to a scarce resource (workshop 111).

And if the block is abandoned?

If a reorganisation replaces the block, its transactions go back into the mempool, unless the winning branch already contains them. A transaction may then move to another block, or even, if it conflicts with another transaction already confirmed on the winning branch, become invalid.

What this does NOT guarantee

• Being in a mempool does not guarantee inclusion: a node may evict transactions when its queue is full.
• Seeing your transaction in your node does not mean others see it.
• No node is obliged to include a particular transaction: a proposer can censor it, and the network relies on proposer rotation.
• "Included in a block" is not "finalised": see workshop 109.

Recap

Sign, broadcast, validate, wait in each node's mempool, be picked, be put in a block, see that block validated by everyone, then gain finality. Each stage has its own guarantee, and none implies the next.

Two things not to confuse: transactions and state

Transactions are events ("Awa pays 50 to Bineta"). The state is the result of all events since genesis: who owns what now. In an account model (workshop 111), the state is, for example, the table of balances and nonces. A node that replays all the transactions rebuilds the state. But how do two nodes quickly check that they agree on that state?

The idea: a fingerprint of the state

Arrange the state in a Merkle tree (workshop 106) whose leaves are the accounts. The root of that tree is the state root. A header that contains the state root commits to the state of every account after that block.

Toy example: four accounts, leaf = "name:balance:nonce".

Awa paid 50 plus a fee of 1 to a proposer (here the proposer holds the Dayo account, which receives 1): Awa's balance goes from 200 to 149, her nonce from 7 to 8, Bineta gains 50, Dayo gains 1. Those three leaves change, so the root changes. If two nodes compute the same root after the same block, they have the same state; if they get two different roots, at least one executed the block differently. Try it in merkle-explorer: edit a leaf and watch the root change.

What is the state root for?

1. Fast agreement: comparing 32 bytes is enough to check that two nodes hold the same state.
2. Proofs for light clients: a client that keeps only headers can receive a balance with a Merkle proof and verify it against the header's root.
3. Synchronisation: a new node can check a state snapshot against a root.

Not every network has the same one

• In Bitcoin, the header contains no state root: it contains the Merkle root of the transactions. To know what is still unspent, full nodes maintain the set of unspent outputs (UTXO set) locally, without the header committing to it.
• In Ethereum, the header contains a state root, plus a transactions root and a receipts root. The state is organised in a more elaborate tree than a binary Merkle tree (a Merkle-Patricia trie), but the commitment principle is the same.
• In CometBFT (Cosmos), the header contains an app_hash field, computed by the application, that commits to the application state. It is computed with a delay: a block's app_hash reflects the state after executing the previous block.

What this does NOT guarantee

• A state root in a header does not prove it is correct: only executing the transactions checks it. A malicious miner or validator can propose a false root; full nodes reject it by replaying the block.
• A light client verifying a proof against a root assumes the header itself is valid (consensus).
• The state root does not say why the state changed: you need the transactions for history.

Recap

Transactions = events, state = consequences, state root = a single fingerprint of the consequences. It lets nodes agree and lets light clients verify a balance.

The client that downloads only headers

A phone on a metered connection cannot download hundreds of gigabytes of blocks. The simplified payment verification section of Nakamoto's paper (Bitcoin: A Peer-to-Peer Electronic Cash System) describes a client that keeps only the longest chain's headers (in practice, the one with the most cumulative work) and asks for a Merkle branch for a transaction it cares about. What can it actually conclude?

What a header lets you verify alone

• The link to the parent: the parent's hash is in the header, so a chain of headers is verified step by step.
• The work (proof of work): is the header's hash below the target, and is that target the one the difficulty-adjustment rules require at that height? A header that declares a very easy target itself proves almost nothing: the bits field must also be compared with that of the previous blocks. The computation to redo is still a double SHA-256 of 80 bytes.
• A transaction's inclusion, with a Merkle proof: is the transaction under the header's root? (workshop 106)
• A balance, in a network that has a state root, with a proof against that root.

What still requires the body (and execution)

• The validity of the transactions: correct signatures, no double spend, sufficient balances. A header can commit to invalid transactions.
• The correctness of the state root: only executing the transactions checks it.
• Data availability: the header does not prove the body was published.
• The absence of a transaction: an inclusion proof shows an item is present, not that another is absent (except with particular structures: workshop 106).
• Being on the right chain: a light client sees the headers its peers show it; if they are all malicious, or if it is eclipsed (workshop 107), it may follow a chain the rest of the world has abandoned.

Example: a proof that fails

The client receives a transaction T, its proof (the siblings at each level) and the root announced by the header. It recomputes: hash of T, then combines with each sibling, from the bottom up. If the final result equals the root, T is in the block; otherwise either the transaction was modified, or the proof is wrong, or the server is lying. A single changed byte of T changes the result (avalanche, workshop 104). You will do this in the security exercise.

What this does NOT guarantee

• A valid Merkle proof says nothing about the block's depth or finality: you must also know where the header sits in the chain.
• It does not say the transaction succeeded: in contract chains, an included transaction may have failed during execution (the receipt says so).
• Light clients trust consensus: if the majority of power (or more than one third of validators) is malicious, an invalid header can look valid.

Recap

A header proves the link, work that matches the required target, or the consensus signature, and (with a proof) inclusion. It proves neither the validity of the transactions, nor the correctness of the state, nor data availability.