Forks and upgrades

A blockchain’s rules live in software that many independent people run. Changing a rule means getting all of them to change at the same moment, or the network splits into nodes that accept a block and nodes that don’t.

Pearl’s answer is simple: pick a block height, write it into the next release, and give everyone time to upgrade. When the chain reaches that height, the new rule applies, on every up-to-date node at once. Four rules have changed this way so far.

What is a fork?

The word has two meanings in blockchains.

• A chain split: two blocks on the same parent, for a moment. That’s ordinary and resolves itself; see the most-work chain.
• A rule change: a new version of the rules. That’s this page.

Rule changes come in two kinds:

How does Pearl schedule a change?

With a number in the chain parameters. Each fork has a height, and helper functions like IsMoEForkActive(height) answer “does this rule apply here?” Nodes check the certificate rules for every block against its height. The software even refuses to start if the rank-penalty or salted-seed height is set before the MoE height, since both rules assume V2 certificates exist.

Miners don’t vote. The header’s version field still carries Bitcoin’s BIP-9 version bits, but Pearl’s mainnet defines only three test dummy deployments. Blocks from about 2,100 to 100,799 carry version 0x20400000 (bit 22 set), most likely because of one of those dummies; either way it means nothing. See version.

What are the four forks?

All four touch the mining certificate, never transactions or the header layout.

MoE hard fork, block 71,935

From this height, blocks must carry a V2 certificate instead of V1. V2 made the certificate’s public data variable in length, so it could describe mixture-of-experts jobs: the matrix multiplications inside MoE layers of large language models, where each token is routed to a few “expert” weight matrices.

Dense proofs, the ordinary kind, stayed valid in V2, so hashing miners didn’t need to change. Nodes and the software that turns a share into a certificate did: an old node rejects a V2 certificate. That’s what made it hard.

Dense-only soft fork, block 91,630

From this height, a V2 certificate must be dense: public data longer than 164 bytes (an MoE proof) is rejected. The set of valid blocks only shrank, so old nodes kept accepting everything, a soft fork. The height moved from 91,600 to 91,630 during development, after a fix for empty block templates being mistaken for MoE.

Why MoE proofs were switched off again hasn’t been published. MoE support continues in Pearl’s separate FP8 work, which is not live.

Rank-penalty soft fork, block 96,251

From this height, the noise rank must be at least 128, and a certificate with a higher rank faces a stricter bar, scaled by 128 ÷ rank. Pearl’s own explanation: a proof’s ticket bar “is scaled by the work one attempt costs, and the noise rank divides that work, so mining at a larger rank buys a proportionally easier bound for the same effort.” The penalty cancels that advantage. Details are on rank penalty.

Salted noise-seed hard fork, block 99,000

From this height, blocks must carry a V3 certificate. The bytes are laid out exactly like V2; what changed is how the noise seeds are derived. Each matrix fingerprint is now salted with the matrix size the miner claims, so one committed matrix can no longer be “read” under several shapes to collect extra tickets, a form of work amplification.

Because the noise changed, miners had to upgrade too this time. The height moved twice in development, from 98,830 to 98,900 to 99,000. A related security advisory is referenced in Pearl’s code history but not public; see noise seeds.

Can you see the forks on chain?

Yes, in the very first bytes of each raw block, which start with the certificate version:

Here is block 1’s certificate, a V1, and block 130,827’s, a V3:

Are any other changes scheduled?

Not in v1.5.2. A search of the code finds no other height-gated rules, and the v1.5.x releases add no new fork height. Two smaller changes in those releases apply without a height: OP_CHECKXMSSSIG now fails on a wrong-length key or signature chunk, and spending an output created later in the same block is rejected, as in Bitcoin Core.

Pearl Research Labs is working on a new mining scheme (FP8) with a certificate V4. It is not live; if it ships, it will be another fork with its own height.

func (p *Params) RequiredCertVersion(height int32) wire.CertificateVersion {
	if p.IsSaltedSeedForkActive(height) {
		return wire.CertificateVersionV3
	}
	if p.IsMoEForkActive(height) {
		return wire.CertificateVersionV2
	}
	return wire.CertificateVersionV1
}