← All posts
7 min read

Finality you can carry in your pocket: BEEFY and MMR are live on QBC

QBC ships BEEFY and MMR: an additive finality proof layer that lets a phone or another chain verify QBC finality from one signed commitment plus a proof. The groundwork for trustless bridges and thousand-voter finality.

Finalizing a block and proving that it was finalized are two different problems. QBC has had the first one solved for a long time: GRANDPA gives every block on this chain deterministic finality, so once a block is finalized it never reverts. What GRANDPA does not give you cheaply is the second thing, a small piece of evidence that an outside party who is not running a full node can check for itself. That is the gap BEEFY closes, and as of today BEEFY and its companion MMR are live on the chain at spec version 172.

What BEEFY and MMR actually are

BEEFY stands for Bridge Efficiency Enabling Finality Yielder, which is a mouthful that hides a simple idea. It is a second signature layer that rides on top of GRANDPA. GRANDPA stays exactly as it was and remains the only thing that finalizes blocks. BEEFY adds a parallel process where the validators periodically sign a short commitment that says, in effect, "the canonical chain up to here has this root." Those signed commitments are the portable proof.

The root they sign over comes from the MMR, the Merkle Mountain Range. An MMR is an append-only Merkle structure that accumulates one leaf per block, where each leaf carries that block's identifying data. Because it is append-only and Merkle-shaped, you can prove that any single block belongs to the chain with a compact inclusion proof, a handful of hashes rather than the whole history. Put the two together and you get the payoff: a validator-signed commitment over the MMR root, plus a Merkle proof for the block you care about, is enough for anyone to verify that a given QBC block is final. No full node, no trust in a middleman.

Why this matters

Two reasons, and they are the reasons BEEFY exists in the Substrate ecosystem at all.

The first is bridges and light clients. If another chain, or a light client on a phone, wants to confirm that something happened on QBC, today it would have to trust an operator or run heavy infrastructure. With BEEFY it can verify a signed commitment against the known validator set and check a Merkle proof, both cheap operations that fit inside a smart contract on another chain. This is the standard mechanism that trustless bridges are built on, and it is now available on QBC. We store the BEEFY validator keys in a form that maps cleanly onto Ethereum-style addresses, precisely so that an Ethereum-side verifier can check QBC finality without exotic cryptography.

The second reason is scale. Our north star for the base chain is finality that holds not with a handful of validators but with thousands. GRANDPA justifications are perfectly good at small validator counts, but the portable, aggregatable commitment that BEEFY produces is the shape of proof you want when the voter set gets large. BEEFY is not the thing that makes a thousand voters finalize, but it is the substrate that makes their finality cheaply provable to the outside world. Shipping it now, while the set is small and the chain is calm, is how you earn the right to grow it later.

Shipping a consensus change without breaking consensus

The interesting engineering story here is not the feature, it is how you add a layer this deep to a live chain without taking it down. A halt on a running chain is not a bug you fix after the fact. It is every node down at once with no automatic recovery. So the whole exercise was built around one principle: BEEFY is additive and isolated. GRANDPA is never touched. The BEEFY process runs as its own task that, if it ever misbehaves, dies alone and leaves block production and finality completely unaffected. Worst case, the new layer simply produces nothing.

There was exactly one delicate part. To sign BEEFY commitments, each validator needs a new kind of key, so the on-chain record of validator session keys had to grow from two keys to three. On a genesis-frozen chain, that shape change is a trap. The keys already stored on chain are in the old two-key format, and if the runtime tries to read them as three-key records it reads them as empty. The next time the validator set rotated, which happens roughly every half hour, an empty read would have wiped the validator set and halted the chain.

We caught this in an adversarial review before anything was deployed, not after. The fix is a migration that runs once during the upgrade and rewrites every validator's stored keys into the new three-key format, so the set is never seen as empty. Then we did the thing that makes this kind of change safe to ship: we rehearsed the entire upgrade against a real copy of the live chain state using try-runtime, replaying the migration over nine hundred thousand live storage keys and checking that every part of the runtime still validated afterward. The rehearsal ran green, including a built-in check that the migration is safe to run twice. Only then did we upgrade the live chain.

The upgrade landed cleanly. The migration re-encoded the validator keys, the validator set stayed full, and finality never wavered. The real test came about half an hour later at the first live validator rotation, the exact moment the un-migrated version would have halted. The set stayed intact and the chain rotated normally. That is the whole point of rehearsing against live state: the scary moment was boring, because we had already watched it happen on a copy.

Armed, and honest about where this sits

With the layer proven stable, the validators registered their real BEEFY keys and we armed the process. BEEFY consensus is now enabled on the chain, and the validators produce signed commitments over the MMR root as blocks finalize.

It is worth being precise about what this is and is not. BEEFY going live does not by itself make QBC a thousand-node network. It is the groundwork, the proof format and the on-chain plumbing, that makes trustless bridges buildable and makes large-scale finality provable. The work that still stands between here and a public network of that size is honest and unglamorous: a real multi-machine testnet at scale, an external security audit, and moving the chain's administrative key off a development key and onto operator-held multisig custody. None of those are new consensus problems. They are the diligence that turns working machinery into something you would invite the world onto.

What shipped today is a piece of that machinery, added to a live chain, rehearsed against its own state, and deployed without a single dropped block. The chain that finalizes a mind can now hand you a proof of its own finality small enough to carry anywhere.

Further reading

ShareXLinkedIn

Written by

A
Ash Brown@blockartica
Founder, SusyLabs / QuantumAI Blockchain

Building the post-quantum AI-native L1 with permissionless on-chain training cycles. Writes about consensus, attestation, and the gap between what ships and what's claimed.

Related posts