Proving the work

Multiplying matrices is the easy part to describe. The hard part is the proof.

How does the rest of the network know a miner really did the work, without redoing it and without even seeing the matrices? This page follows one miner through the whole puzzle, simplified but in the right order.

Why can’t miners just reuse old answers?

If the puzzle were only “multiply two matrices”, a miner could do one big multiplication and present it again for every block. Or it could pick special matrices that are suspiciously easy to multiply.

Pearl blocks both tricks with noise: random-looking numbers that must be added to both matrices before multiplying.

The noise isn’t chosen by the miner. It’s computed from the block the miner is working on and from fingerprints of the two matrices. Change a single transaction, the time, or one number in either matrix, and the noise comes out different. So every attempt needs fresh work, and there’s nothing to prepare in advance.

What is the noise, exactly?

The noise starts from two noise seeds, random-looking values made with the BLAKE3 hash function. Each seed is stretched into a grid of noise for one matrix.

The grids are built cheaply, as a thin random matrix times a simple pattern of plus and minus ones. Mathematicians call that “low rank” (here, rank 128), and it means the noise is cheap to add and just as cheap to remove afterwards.

How does a multiplication become lottery tickets?

The answer grid is cut into small patches called tiles, of 128 cells each in the official miner.

Each answer cell is a long sum of multiply-and-add steps. While the GPU works through those sums, it pauses every 128 steps and folds the tile’s running totals into a short record, a kind of diary of the work in progress. That diary is the tile’s transcript.

When the tile is finished, the diary is hashed into a 256-bit number. That number is a lottery ticket. A big multiplication produces millions of them.

Why a diary and not just the final answer? Because a final answer can be faked cheaply from an old one, but the running totals along the way can’t, as far as anyone knows. To get the diary, you have to do the multiplication.

How does a ticket win?

The network sets a target. A ticket wins if, read as a number, it is no bigger than the target times the amount of work that tile cost.

That scaling is deliberate: it gives every multiply-accumulate the same tiny chance of winning, however the miner shapes its matrices.

What happens, step by step?

Here is the whole puzzle in order. The interactive miner below the list runs these steps on tiny matrices.

1. Start from a block template

   The miner prepares a block: previous block, transactions, time and target. No nonce.

2. Choose two matrices

   Any two grids of whole numbers in the range [−64, 64]. In the official miner, they come from a real AI model.

3. Fingerprint everything

   BLAKE3 hashes the block template into a job key, then uses it to fingerprint both matrices.

4. Roll the noise

   The fingerprints become two noise seeds, and the seeds become the noise.

5. Multiply, keeping a diary

   The GPU multiplies the noisy matrices. Every 128 steps, each tile’s running totals go into its diary.

6. Turn diaries into tickets

   Each finished tile’s diary is hashed into a ticket.

7. Check for a winner

   Each ticket is compared with the scaled target. Almost all lose.

8. Prove the winner

   The pool’s software turns the winning tile into the block’s certificate.

9. Remove the noise

   The miner subtracts the noise’s effect and recovers the product of its original matrices, the useful answer.

What is the certificate?

The miner’s pool receives the winning tile’s ingredients: a couple of rows from one matrix, a few dozen columns from the other, and the fingerprint data proving they belong. Its software turns them into a certificate, which takes several seconds on a good computer.

The certificate is about 60 KB. Almost all of that is a zero-knowledge proof, which says, in effect: “rows matching these fingerprints, plus this public noise, really produce this winning ticket”.

The certificate rides in front of the block, and the block header carries a 32-byte fingerprint of its public part, the proof commitment. That ties the proof to this exact block.

What does “zero-knowledge” mean?

It means proving something is true without revealing why it’s true.

Here’s a classic picture of the idea. You’ve found Waldo in a huge Where’s Waldo poster, and want to prove it without giving away where he is. So you cover the poster with a big sheet of cardboard that has one small hole, and line the hole up with Waldo. Your friend sees Waldo through the hole, and learns nothing about where on the poster he’s standing.

Pearl’s proof does the same with arithmetic. Nodes learn that a winning ticket came from honest matrix work, and nothing about the matrices themselves. (The real math is nothing like cardboard; this is only the idea.)

How fast can anyone check it?

Very fast. In tests run for this site on an Apple M5 Max processor, building a proof took 5.7–17 s, while checking one took 7–21 ms.

That gap is the point: mining is slow and expensive, checking is quick and nearly free, so every node can verify every block for itself.

Certificate on mainnet

59,768 bytes

Of which the proof

59,560 bytes

Time to check

7–21 ms

Apple M5 Max CPU

Time to prove

5.7–17 s

once per block, not per ticket

Make a guess

A miner finishes a huge multiplication, but none of its tickets win. Can it reuse the same result for the next block?

Think of your answer first, then check it.

Reveal the answer

Answer No.

The next block has a different template: a new previous block, at least. That changes the job key, so the noise seeds change, so the noise changes, so every diary and every ticket changes. The old work is spent, like scratched lottery cards.

One question is left from the ticket rule: who sets the target, and why does it keep changing? That’s the next page.