Certificate

A Bitcoin block proves its own work: anyone can hash its header and see that the result is small enough. A Pearl block can’t, because its work is a huge matrix multiplication on private data. So every Pearl block carries a separate proof, its certificate.

Think of it as a sealed envelope with a label. The label, the public data, says in 164 bytes which puzzle was solved and which lottery ticket won. The envelope holds a zero-knowledge proof, about 60 KB, that the label is true. Nodes read the label, check the proof, and never see the matrices.

This page is about the bytes. How the certificate is made and what the proof proves are on the certificate (mining) and zero-knowledge proofs.

What’s in a certificate?

Block 130,825’s certificate, field by field. The proof is collapsed to its first bytes; it would fill this page many times over.

Which versions exist?

Three real ones, each required in its own range of heights, plus an empty placeholder:

• Version 2 came with the Mixture-of-Experts hard fork at block 71,935. Its public data could be longer than 164 bytes, up to 4,807, to describe expert routing; hence the length field. From block 91,630 a soft fork rejects anything longer than 164 again, so mainnet certificates are dense.
• Version 3 came with the salted noise-seed hard fork at block 99,000. Not one byte of the format changed. What changed is how the verifier reads it: the noise seeds now also commit to the matrix sizes, and the proof commitment hashes a 3. See noise seeds.
• Version 0 is a bare 00000000: “no certificate here”. It stands in for certificates in block templates and in headers replies sent without certificates.

The genesis block has a stand-in version 1 certificate: its block hash, 164 zero bytes of public data and a 4-byte “proof”, deadbeef. That’s 208 bytes, and it’s never checked.

What’s in the public data?

Twelve fields in 164 bytes. Here they are for block 130,825, decoded:

The first 52 bytes are the mining configuration; the job key hashes them along with the header. Together the fields say: “A 131,072 × 8,192 matrix times an 8,192 × 262,144 matrix, with rank-128 noise, cut into 2 × 64 tiles; the tile starting at row 103,168, column 188,674 produced this ticket.” That’s a multiplication of about 2.8 × 10¹⁴ multiply-accumulates, of which the winning tile is 1,048,576.

What’s in the proof bytes?

A short preamble, then the proof itself:

These are settings of the proof system, not of the mining. Block 1’s proof starts 12 12 16 02 03 07: the same, except a rate of 2 for the first layer. (Comments in Pearl’s code describe a 32-byte “preprocessed digest” in the preamble; the actual format carries the 16-byte zeta instead.)

How big can it be, and does it count?

Certificate today

59,768 B

4 + 32 + 4 + 164 + 4 + 59,560

Proof today

59,560 B

same at k = 2,048 and 8,192

Public data

164 B

dense; MoE was longer

Proof cap

60,000 B

MaxZKProofSize

Certificate cap

65,000 B

CertificateMaxSize

Counted in vsize

0 vB

excluded by consensus

The proof barely changes size with the size of the multiplication. In the research for this site, proofs for k = 2,048 and k = 8,192 were both exactly 59,560 bytes.

The block size limit, 1,000,000 vbytes, counts the header and transactions (witness bytes at a quarter) and not the certificate. Pearl’s code says why in one line: the certificate is “proof metadata, not block data”. The certificate sits on top of the 4,000,000-byte cap for header and transactions, so the largest possible block message is 4,065,000 bytes.

That’s why sizes disagree. Block 130,827 is 64,379 bytes on disk and on explorers like Blockbook, but only 2,795 vbytes to consensus. A block holding nothing but its coinbase shows up as roughly 60 KB.

Where does the certificate travel?

Everywhere the header goes:

• In blocks, first: certificate, then header, then transactions. See blocks.
• In header sync. A headers message carries up to 100 entries, each a certificate (or 00000000) followed by a 108-byte header. Nodes verify every certificate while syncing headers.
• To light clients, which also verify each header’s certificate. So a Pearl light client downloads about 60 KB per block header, where a Bitcoin light client needs 80 bytes.

func (c *CertificateV2) Serialize(w io.Writer) error {
	w.Write(c.Hash[:])                                             // 32
	binary.Write(w, binary.LittleEndian, c.PublicDataLen)          // 4
	w.Write(c.PublicDataBytes())                                   // 164
	binary.Write(w, binary.LittleEndian, uint32(len(c.ProofData))) // 4
	w.Write(c.ProofData)                                           // 59,560
	return nil
}