Previous block

Every block points back at the block before it. The pointer is the parent’s block hash, written into the second field of the header.

That’s the whole trick behind a blockchain. Each block names its parent by a fingerprint of the parent’s header. The parent names its own parent, and so on, all the way back to the genesis block. Change any old block and its fingerprint changes, and every link after it breaks.

Try it

Edit a block in the middle of a short chain and watch every later block turn invalid.

What does it look like?

Size

32 bytes

Type

SHA256d hash of the parent's header

Format

Internal byte order (shown reversed)

Bytes 4 to 35 of block 130,827’s header are:

999c961b04d94b8b21134e862dc31d5fa56cf9d1f027adb2a0cf95c6525c55eb

Reverse them byte by byte and you get the hash of block 130,826, as any explorer shows it:

Why is it stored backwards?

It isn’t, quite. A hash comes out of SHA-256 as 32 bytes in a fixed order, and that’s the order the header stores. This is the internal byte order.

When Bitcoin’s software prints a hash, it reverses the bytes, treating the hash as one big little-endian number written the usual way, biggest digit first. Pearl inherited that habit unchanged, so every block hash and transaction ID you see on an explorer is the reverse of the bytes on the wire. See byte order.

Where does the chain start?

At genesis, which has no parent. Its previous-block field is 32 zero bytes.

Block 1 is the first real link. Its previous-block field holds the genesis hash, stored reversed:

What does the link protect?

Everything before it. Here is the chain of consequences if someone edits one transaction in an old block:

1. The old block's Merkle root changes

   The transaction’s ID changes, so the Merkle root in that block’s header changes.

2. So its block hash changes

   The block hash is SHA256d of all 108 header bytes, Merkle root included.

3. So the next block's link is broken

   The next block’s previous-block field still holds the old hash. To fix it, that header must change too, which changes its hash, which breaks the block after it.

4. So every later block needs new mining work

   Each rewritten header needs a valid certificate, and a certificate is bound to its header’s first 76 bytes, previous block included. The attacker must redo the mining work of every block up to the tip, faster than the honest network adds new ones.

On Pearl the links cover more than in Bitcoin. A Pearl header ends with a proof commitment, a hash of the certificate’s public data. So the chain of block hashes also chains every winning ticket since genesis.

Can a block’s parent be any block?

The parent must be a block the node already knows, and the new block’s height is the parent’s plus one. Two blocks can share a parent; that’s a fork, and nodes follow the chain with the most work, as in Bitcoin, with one Pearl twist (a switch needs a small extra margin of work). See the most-work chain.

Pearl’s nodes also carry checkpoints, one every 10,000 blocks, and refuse any fork that branches off below the latest one (block 120,000 in v1.5.2).

Why does mining care about the parent?

Because the previous block is part of the mining puzzle itself. A Pearl miner hashes the first 76 bytes of its block template (version, previous block, Merkle root, time and bits) together with its mining settings into a job key. All the puzzle’s randomness flows from that key: the noise seeds, the noise, and therefore every lottery ticket. See noise seeds.

func (hash Hash) String() string {
	for i := 0; i < HashSize/2; i++ {
		hash[i], hash[HashSize-1-i] = hash[HashSize-1-i], hash[i]
	}
	return hex.EncodeToString(hash[:])
}