Chain of blocks

What it does

Five toy blocks, each holding a line of text and the hash of the block before it. Each block’s own hash is SHA256d of a small header made of its height, that previous hash and a hash of its text.

How to read it

• Edit any block’s text, or press Tamper with block 2. That block’s hash changes, so the next block’s “prev” no longer matches (struck through in red), and every block after it now sits on a broken block.
• Re-link the chain points each later block at its parent’s new hash, one at a time. Each fix changes that block’s hash too, so the repair has to cascade to the end.

Pearl specifics

Here re-linking is free. In Pearl, a block hash covers the 108-byte header, whose last field commits to a winning ticket, and the ticket came from a mining job keyed by the template, previous block’s hash included. Change a parent and the old ticket is worthless: every re-linked block must be mined again. That is why history gets harder to rewrite with every block on top, and why nodes follow the chain with the most work.

What’s simplified

The header is a toy (height, previous hash, hash of the text). Real Pearl headers are 108 bytes: version, previous block, Merkle root, time, bits and proof commitment.

Under the hood

Runs entirely in your browser, with SHA256d from src/lib/hash.ts (unit-tested against real Pearl block and transaction hashes).