Block hash

Every block has a name: its block hash. It’s a 32-byte fingerprint of the header, written as 64 hex digits, and it’s how everyone refers to a block.

If you know Bitcoin, you know block hashes as long strings that start with a row of zeros, because in Bitcoin the hash is the proof of work. Pearl block hashes don’t look like that. They look completely random, because on Pearl the block hash has only one job: to be the block’s ID.

Try it

Hash anything with SHA256d. Change one character and watch about half the bits of the output flip.

How is it computed?

Hash the 108-byte header with SHA-256, hash the result with SHA-256 again (SHA256d), and reverse the 32 bytes for display:

For block 130,827, SHA256d of those 108 bytes comes out as b9456d3c…c1f2f21d in internal byte order. Reversed, that’s the hash every explorer shows:

The algorithm is Bitcoin’s, unchanged. Only the input is longer: 108 bytes instead of 80.

Why doesn’t it start with zeros?

Because nothing requires it to. Here are four real Pearl block hashes:

In Bitcoin, a miner keeps changing the header until its hash, read as a number, is below the target. Pearl miners never do that. The number that has to beat the target is a different hash, a BLAKE3 ticket called hash_jackpot, stored inside the block’s certificate. See tickets and target.

What does the hash cover?

Everything in the header, and through it almost everything in the block:

• The parent, through the previous-block field, and so, link by link, the whole chain back to genesis.
• The transactions, through the Merkle root, and their witnesses through the coinbase’s witness commitment (when the block has any witness data).
• The time and the target, directly.
• The mining result: through the proof commitment, the mining settings, both matrix fingerprints, the winning ticket, the matrix sizes and the tile position.

One thing is deliberately left out: the zero-knowledge proof bytes. Proofs are randomized, so the same block could carry different valid proofs, and the block hash must not depend on which one.

Where is the block hash used?

As the block’s name, everywhere:

• The next block stores it in its previous-block field.
• The certificate stores it too, in internal byte order, and a node rejects a certificate whose stored hash doesn’t match the header’s.
• Checkpoints in the node software are lists of block hashes: block 120,000 must be a5f57e44…d2a84b7d, and so on every 10,000 blocks.
• Explorers, wallets and peers ask for blocks by hash.

Why is it still SHA-256?

Because Pearl kept Bitcoin’s hash wherever it kept Bitcoin’s design. Block hashes, transaction IDs, the transaction Merkle tree and the proof commitment all use SHA256d, exactly as Bitcoin’s equivalents do.

BLAKE3 appears only inside the mining puzzle: the job key, the matrix fingerprints, the noise seeds and the tickets. There its strengths matter: it is natively a Merkle tree, so a gigabyte-sized matrix can be committed to and opened a few rows at a time; it is fast on GPUs; and it has a keyed mode. See hash functions.

Why does the certificate repeat the block hash?

So a node can pair a certificate with its header before doing any real work. The first check in certificate verification is simply “does the hash stored in the certificate equal SHA256d of this header?”. A certificate copied onto another header fails at once, before the expensive proof check. Light clients rely on the same pairing: they download each header with its certificate, verify both, and keep only the 108-byte header afterwards.

Can a miner choose its block hash?

Only by changing the block. Any change to the header gives a completely different hash (the avalanche effect), and any change to the first 76 bytes also gives the miner a completely different mining puzzle. Since no rule cares what the hash looks like, there’s no reason to try.

// BlockHash computes the block identifier hash for the given block header.
func (h *BlockHeader) BlockHash() chainhash.Hash {
	return chainhash.DoubleHashRaw(func(w io.Writer) error {
		return writeBlockHeader(w, 0, h)
	})
}

import { sha256 } from '@noble/hashes/sha2.js';
import { hexToBytes, bytesToHex } from '@noble/hashes/utils.js';

const header = hexToBytes('00000020999c961b…c77ae649');   // all 108 bytes
const hash = bytesToHex(sha256(sha256(header)).reverse()); // '1df2f2c1…3c6d45b9'