Blocks

A block is a batch of transactions with a short summary on top. That summary is the block header, and on Pearl it is exactly 108 bytes long.

The header does two jobs. It links the block to the one before it, so the blocks form a chain. And it pins down everything inside the block, so that changing a single byte anywhere would be noticed.

This page walks through a real header from Pearl’s mainnet, field by field, then shows where the header sits inside a whole block. Each field has its own page.

Try it

Edit any field of a real header. The block hash changes completely, and the link to the next block breaks.

What’s in a header?

Here are the 108 bytes of block 130,827, colored by field. Hover a field to see its name and value.

Six fields, always in this order:

The sizes add up: 4 + 32 + 32 + 4 + 4 + 32 = 108. Pearl’s code builds that number the same way, as 12 bytes of small fields plus three 32-byte hashes.

How do you read those bytes?

Field by field, using block 130,827. Numbers are stored little-endian (smallest byte first), and hashes are stored byte-reversed, exactly as in Bitcoin. So most fields read “backwards”.

Hash all 108 bytes twice with SHA-256 and reverse the result, and you get the block’s ID, its block hash: 1df2f2c1bf39b1a444e622c1788c11736da2f91f4e9a875a38dc23063c6d45b9.

Notice that the hash doesn’t start with a row of zeros. On Pearl it never does, because the block hash is not what the mining puzzle checks. See block hash.

How is it different from Bitcoin’s header?

The first five fields are Bitcoin’s, byte for byte in format. The last one is new.

Where does the header sit in a block?

Not at the start. On the wire and on disk, a Pearl block is laid out certificate first:

• The certificate comes first: its version, the block hash it proves, 164 bytes of public data, and a zero-knowledge proof of 59,560 bytes. See certificate.
• Then the 108-byte header.
• Then a CompactSize count of transactions, and the transactions themselves, coinbase first, in the same format as Bitcoin’s (with witness data).

Headers travel the same way between nodes: each header in a headers message is preceded by its certificate (or by an empty 00000000 when certificates weren’t asked for), at most 100 per message. A node verifies every certificate as it syncs headers.

What does a node check in the header?

When a block arrives, a node checks every header field against the rules:

• Previous block must be a block it knows, and the new block’s height is one more.
• Merkle root must match the transactions actually in the block.
• Time must be at least 1 second after the parent’s and at most 5 minutes ahead of the network-adjusted clock.
• Bits must equal the value the difficulty rule (WTEMA) computes from the parent.
• Proof commitment must equal SHA256d of the certificate’s version and public data, and the certificate must name this header’s hash.
• The certificate’s proof must verify, and its ticket must beat the target scaled by the tile’s work.

The version field is the one thing nobody checks. See version.

littleEndian.PutUint32(buf[:4], uint32(bh.Version))   // 4 bytes
w.Write(bh.PrevBlock[:])                               // 32 bytes, internal order
w.Write(bh.MerkleRoot[:])                              // 32 bytes, internal order
littleEndian.PutUint32(buf[:4], uint32(bh.Timestamp.Unix()))
littleEndian.PutUint32(buf[:4], bh.Bits)
w.Write(bh.ProofCommitment[:])                         // 32 bytes: no nonce