How Solidus Decides Which Chain Is Real: Not the Longest One, and You Cannot Watch It Happen

It is not the longest chain

A proposer does not extend whichever branch has the most blocks. It extends the branch carrying the highest certificate it has seen.

So "which chain is real" is decided by certificates rather than by length, and a longer branch without certificates loses to a shorter one that has them.

The three rules, as the code states them

One: the proposal's round must match the round the participant is currently in. A proposal from a different round is not voted on at all.

Two: the leader proof must verify, and the proposer must be in the validator set. A proposal from somebody outside that set is rejected before anything else is considered.

Three: the safety lock. A participant keeps a locked certificate, and will only vote for a proposal whose parent certificate is at least as recent as that lock, or which directly extends the locked block.

The lock moves one behind. When a higher certificate arrives, the previous highest becomes the new lock, and the new one becomes highest.

And finality is two rounds later

A block is committed when its round is at least two below the highest certificate.

So a block is not final when it is certified. It is final when two further rounds have been certified on top of it, which is why a chain like this one can show you a recent block that is not yet irreversible.

And you cannot observe any of it

Every input to those rules is absent from the public read surface.

No certificate, as measured on the certificate page. No parent certificate on a block. No lock. No leader proof.

CONTROL: a block does carry its proposer and its round, so these are absent rather than the response being cut short.

So the decision that determines which chain is real is made entirely out of sight. You can see the outcome, which is a sequence of blocks, and none of the evidence that produced it.

A bug the code documents on itself

The certificate update once compared rounds against a zero sentinel rather than against the absence of a certificate.

The effect: a round-zero certificate was silently dropped, because zero is not greater than zero. The next proposer then built as though no certificate existed, parented its block on the genesis placeholder, and orphaned the round-zero block from the canonical chain.

And the comment records how the severity changed. Under the older free-running behaviour the orphaned block was an empty throwaway. Under event-driven proposing it is the first transaction-bearing block after every restart.

That is a fixed bug, explained in place, with its blast radius stated honestly. A comment that tells you a defect got worse before it was caught is worth more than one that says the code is correct.

One coincidence we are naming and not claiming

This chain currently produces three blocks in a burst, then falls silent.

Three is also the number of rounds the commit rule needs, a block plus two certified on top.

We are not claiming those are the same three. We cannot see certificates or rounds beyond what a block reports, so the resemblance is a shape, not a finding, and somebody with the node's internals can tell in one read whether it means anything.

What you can check yourself

solidus_getBlock with a height, then compare its round against its height

They are not the same number, and the gap between them is one of the few consensus-shaped things a reader can actually observe from outside.