HYPERSCALE · FORK SAFETY

Why the chain cannot fork.

A committee where up to a third are corrupt. Two competing petitions. And one stubborn arithmetic fact: any two supermajorities must share an honest member. The deepest safety property in the system rests on a proof you can check on your fingers — used twice.

01 · The stakes

The cardinal sin

A fork is two versions of history, both claiming to be final: block #100 says Ada's coin went to Bo, the other block #100 says it went to Cy, and different parts of the world believe different copies. Every promise a blockchain makes collapses at that moment — "final" meant nothing, and the same coin was spent twice.

For Hyperscale the stakes compound, because everything else in the system leans on each shard having exactly one history: cross-shard transfers prove state against a shard's committed blocks (the generals), the beacon records each shard's boundary blocks as fact (the clock), and a dying shard's will is read from its one true chain. A forked shard wouldn't just double-spend locally — it would poison every proof drawn from it. So everything narrows to the one property under all the others: within a committee where fewer than a third are corrupt, two conflicting blocks can never both be committed.

02 · The arithmetic

One village, two petitions

Picture a village council of ten electors, of whom at most three are corrupt — you don't know which. Nothing becomes official without a petition signed by seven. Now suppose two competing petitions both claim to have passed in the same session. Count: 7 + 7 = 14 signatures, but only 10 electors exist — so at least 4 people signed both. At most 3 of those can be corrupt. Therefore at least one double-signer is honest.

And an honest elector follows one iron rule: one signature per session, ever. So the fourth double-signer is a contradiction — the second petition can never actually gather its seven. Not because anyone watched for cheating, but because the numbers don't leave room for it.

PETITION A · needs 7 PETITION B · needs 7 even if all 3 corrupt electors sit in the overlap… …the 4th is honest 7 + 7 = 14 signatures · 10 electors · overlap ≥ 4 · corrupt ≤ 3 at least one honest elector signed both — and honest electors don't.
Quorum intersection: check it on your fingers. In protocol terms — committee 3f+1, quorums 2f+1, at most f corrupt: any two quorums share at least f+1 members, at least one honest.

That's the whole engine. In Hyperscale each shard's committee plays the village, a block certificate is a petition (2f+1 signatures out of 3f+1 seats), and the honest one-signature rule is enforced by every validator on itself: at most one vote per round, ever. Two conflicting certificates in the same round are arithmetically impossible.

03 · The twist

Two certificates can exist. Two commits cannot.

Here's the part that surprises people who expect the obvious defense to be the whole defense. Rounds don't always succeed — a proposer stalls, the round times out, a new round begins (timeouts also burn rounds). And across different rounds, two sibling blocks at the same height genuinely can each gather a full certificate, without a single honest validator breaking any rule. The system does not prevent this — and doesn't need to.

Because a certificate is not a commitment. A block commits only when a certificate forms for a child at exactly the next round — an immediate, back-to-back confirmation. And the act of signing that confirmation carries a promise: every signer locks, vowing never again to endorse anything that doesn't build on what they just confirmed. Now the village arithmetic strikes a second time: any future certificate needs 2f+1 signatures, and any 2f+1 must include at least one honest elector from the confirming quorum — a promise-keeper whose lock forbids endorsing the rival branch. The rival may hold a certificate; it can never gather another one on top. It withers.

parent height 99 block B height 100 · round 5 QC ✓ block B′ height 100 · round 7 QC ✓ child C round 6 — contiguous! QC ✓ B COMMITS signers lock on B ✕ every future quorum contains a promise-keeper no next certificate can ever form — the branch withers the overlap, used twice: once per round, once through the locks
The division of labor: the one-vote rule makes same-round conflict impossible; the lock plus the contiguous-commit rule makes cross-round conflict uncommittable.

The design's honest shape: disagreement is allowed to exist; it is only forbidden to matter. Certificates are cheap and can conflict. Commitment is expensive precisely so that the arithmetic can guard it.

04 · The promises

Three rules every honest validator keeps

All of the above compiles down to a tiny personal discipline — two counters each validator maintains against itself, checked before every signature:

◦ ONE VOTE PER ROUND

No second thoughts

Vote or time out — either way the round is spent, forever. A round you gave up on can never be voted afterward, even if the missing block shows up late. (Signing twice anyway is self-proving treason: permanent expulsion — the audit.)

◦ THE LOCK ONLY RISES

Promises don't expire

Once locked on a block, a validator will only ever endorse things that build at least that high. There is no unlock rule — no input, no timeout, no leader's plea can lower it.

◦ NEVER VOTE BLIND

Hold the whole block first

A vote is cast only while holding the block's complete contents — which quietly turns every certificate into a custody receipt too (the archive).

And the promises survive the promiser: both counters are written to disk before any signature leaves the machine, so a validator that crashes and restarts wakes up still bound by every vow it ever made. A promise that could be forgotten by pulling a power cord would be no promise at all.

05 · The hunt

Trying very hard to break it

An argument this load-bearing doesn't get to rest on being persuasive. A dedicated adversarial harness runs shard consensus under hostile scheduling — messages delayed, dropped, reordered, delivered at the cruelest moments a seeded adversary can find — and after every run asserts one thing: no committable fork exists anywhere in the wreckage. Partitioned committees are watched for the correct behavior too: a committee split below quorum halts rather than diverging, and resumes cleanly on heal — safety never depends on timing, only liveness does. Every one of those runs replays byte-for-byte from its seed (the crash lab), so a counterexample, if one ever appeared, would be a permanent exhibit rather than a rumor. The restart case gets its own rehearsal: a crash-restart scenario — its script produced not by a seed but by a model checker holding every possible schedule at once (the proof) — kills a validator mid-promise and asserts the revived node still keeps it.

The lesson: don't build a system where disagreement is impossible — build one where disagreement can't be ratified. Let petitions conflict; make enactment require an immediate confirmation whose signers' promises, by pigeonhole, must surface in every future quorum.

One height, at most one committed block — not by vigilance, but by counting.