The Mechanism Is Real and the Population It Selects From Is Four

Everything below is measured against a four-validator network operated by one party, which is us.

What the mechanism is for

Somebody has to propose each block. If that somebody is predictable, they can be targeted, bribed or prepared for in advance. So the selection has to be unpredictable ahead of time and verifiable afterwards.

A verifiable random function does exactly that: each participant computes a value only they could have computed, everyone else can check it was computed correctly, and nobody could have predicted it. Unpredictable in advance, provable in retrospect.

It is a genuinely elegant piece of machinery, and it is not the interesting part.

The distinction that decides whether it means anything

Selection is real. Scale is not.

A separate round-robin mode exists only for local development and is disabled on the running network, so this is not a case of a fallback quietly serving traffic.

But randomly selecting from four participants operated by one party is a well-implemented ceremony. Unpredictability protects against an adversary choosing which validator to attack. When one operator runs all four, that adversary has one target regardless of what the random function picks.

So the property the mechanism provides is real, and the threat it defends against does not currently exist.

Why we still care that it is real rather than stubbed

Because the failure mode we have documented repeatedly across this site is a mechanism that is described but not running, and this is the opposite: running, in the real configuration, with the development shortcut switched off.

That matters for a specific reason. A selection mechanism that has never actually run has never had its edge cases hit: the tie, the missed round, the participant that appears and disappears. Ours has been running against real rounds, which is how those get found.

"Implemented and exercised at small scale" is a genuinely different state from "specified", and it is worth distinguishing even when the scale makes the security argument moot.

The specification, and the gap to it

The design specifies a 21-of-100 committee. That is a spec. The running network is four validators, operated by one party, which is us.

The gap is not a matter of turning something on. A hundred candidates means a hundred operators, which is a recruitment and incentive problem rather than an engineering one, and it is the same gap every other page on this site eventually reaches.

What is already done is the mechanism, running and exercised. What is not done is the population it was designed for, and no amount of correct cryptography substitutes for that.

How to read any "randomised validator selection" claim

The claim is about the selection. The security is about the population.

A network with excellent randomness and a small operator set has bought very little. A network with mediocre randomness and hundreds of independent operators has bought quite a lot. The vendor talks about the first because it is the part they built.

That is not cynicism about the field. It is that the hard part is recruiting independent operators, which is nobody's favourite thing to write about.

What to ask any network describing its selection

"How many candidates are in the pool, and how many distinct operators run them?" Two numbers, and the second is the one that matters.

"Is the selection mechanism running, or is a simpler mode serving the live network?" Development fallbacks quietly serving traffic is a real pattern. Ours is disabled and that is checkable.

"What is the specified committee size, and the running one?" If those differ, the security argument belongs to the specified one and your risk belongs to the running one.

"What breaks if the selection is predictable?" A project that cannot answer has not modelled the threat the mechanism exists for.

Where this leaves a decision

If your requirement is a network whose validator set is large enough that unpredictable selection matters, ours is not that, and the distance is measured in operators rather than in code.

If you are evaluating whether the machinery is real, it is running, the development shortcut is off, and the honest framing is that a correct mechanism selecting from four processes under one operator is a mechanism waiting for the conditions that would make it load-bearing.