Proof commitment

Bitcoin’s header ends with a nonce, a 4-byte number miners change billions of times a second. Pearl’s header has no nonce. Its last 32 bytes are a proof commitment instead.

A commitment is a hash published as a promise: it pins some data down without carrying it. Here the data is the public part of the block’s certificate: which matrices were multiplied, how, and which lottery ticket won. Because the commitment sits inside the header, the block’s ID vouches for all of that.

Try it

Run the toy miner to the end. Its last steps build 164 bytes of public data, hash them into a proof commitment, and append it to the 76-byte template to make a full 108-byte header.

What does it look like?

Size

32 bytes

Type

SHA256d hash

Format

Raw hash bytes, as SHA-256 outputs them

Bytes 76 to 107 of block 130,827:

4d52a3fd32160cb032e22edf76912f67dfb1b88946a215281f203836c77ae649

Like every hash, it’s stored as SHA-256 produced it. Tools that display it the Bitcoin way reverse it to 49e67ac7…fda3524d. Explorers rarely show it at all.

What is it a hash of?

Of exactly two things, joined together:

Here is the real input for block 130,827, all 168 bytes:

03000000
00200000 8000 0000 070101030000 00010f070000 0000 0000 00000000000000000000000000000000000000000000000000000000
9e1adb4617d7d05111fe2a7e074f81738df4e2181b966ac48f66289b1cab5d4a
d1b42f82cfe36192a36ed37be30a6f9f75e7bca372449aec615e7d0721dc06ef
7540013c2866ec7f6b076e1445f907276b9f27ede2b298603604000000000000
00000200 00000200 84500100 12080100

Line by line: the version (3); the mining settings (k = 8,192, rank 128, an 8 × 16 tile pattern, dense); the fingerprint of matrix A; the fingerprint of matrix B; the winning ticket; and m = 131,072, n = 131,072, tile row 86,148, tile column 67,602. SHA256d of those bytes is 4d52a3fd…c77ae649, exactly the header’s last field. Every field of the public data is explained on certificate.

Why include the version?

To keep certificate versions apart. A version 2 and a version 3 certificate have the same byte layout but derive their noise differently, so the same public data means a different puzzle. Hashing the version in gives them different commitments: block 130,827’s public data under version 2 would commit to b1b8847d…0c4de66f, not 4d52a3fd…. Pearl’s code calls this domain separation, and makes version 3 override the version 2 method just to hash a 3.

Why leave the proof out?

Because zero-knowledge proofs are randomized. The same statement has many valid proofs, and proving the same winning ticket twice gives different bytes.

If the header committed to the proof, two copies of one block could have different hashes. Leaving it out means:

• The block’s ID is fixed early. As soon as a ticket wins, its public data is known, so the commitment, the header and the block hash are final. The slow part, proving (several seconds), happens afterwards and can’t change them.
• Any valid proof will do. A node accepts the block with whichever valid proof it receives.

The proof still can’t be reused for a different block. It is bound to this header and this public data, as the certificate explains.

Isn’t that circular?

It looks circular: the certificate contains the block hash, the block hash covers the proof commitment, and the proof commitment comes from the certificate. But each step only uses things made before it:

The key is that mining only ever reads the first 76 header bytes, through the job key. The proof commitment is computed after mining, from its result. In Pearl’s mining software, the gateway that builds the certificate writes the commitment into the header at that point.

What does a node check?

Two cheap comparisons first, then the expensive check:

1. The certificate names this header

   The block hash stored in the certificate must equal SHA256d of the 108-byte header.

2. The header commits to this certificate

   SHA256d(version ‖ public data), computed from the certificate, must equal the header’s last 32 bytes.

3. The proof verifies against the first 76 bytes

   The Rust verifier gets the version, previous block, Merkle root, time and bits, but not the proof commitment, which would be circular. From them it rebuilds the job key and checks the ticket and the proof.

Together these tie header, public data and proof into one package: a certificate can’t be moved to another block, and a header can’t be paired with another certificate.

What about the genesis block?

Genesis is hard-coded and never verified, and its proof commitment is 32 zero bytes. Its stand-in certificate (164 zero bytes of public data and a 4-byte “proof”, deadbeef) would commit to 1879296c…30466d22 (shown byte-reversed, the way explorers display hashes), so the two don’t even match. It doesn’t matter: no node checks genesis.

// proofCommitment computes SHA256d(CertificateVersion_LE(4) || publicData).
// V3 overrides ProofCommitment to hash version 3 (domain separation from V2).
func proofCommitment(version CertificateVersion, publicData []byte) chainhash.Hash {
	buf := make([]byte, 4+len(publicData))
	binary.LittleEndian.PutUint32(buf[:4], uint32(version))
	copy(buf[4:], publicData)
	return chainhash.DoubleHashH(buf)
}

certHash := cert.BlockHash()
blockHash := header.BlockHash()
if !certHash.IsEqual(&blockHash) { /* block hash mismatch */ }

proofCommitment := cert.ProofCommitment()
if header.ProofCommitment != proofCommitment { /* proof commitment mismatch */ }