Randomness in Committee Selection

Every committee-based protocol eventually asks the same question: who gets to produce the next block, and can anyone predict or influence the answer? Predictable committees are a gift to attackers. They enable adaptive corruption, targeted eclipse attacks, and strategic transaction censorship. This note compares the mechanisms we evaluate when auditing randomness layers.

The threat model

The adversary wants to:

1. Predict the committee in advance to buy or compromise specific validators.
2. Bias the randomness to include more attacker-controlled validators.
3. Abort the randomness generation if the outcome is unfavourable.

A good randomness layer prevents all three. A mediocre one prevents one or two and leaves the third open.

Commit-reveal schemes

A commit-reveal protocol works in two phases: participants publish hashes of their random seeds, then reveal the seeds after a deadline. The seed is combined — usually by XOR or hash — into the final randomness.

Weaknesses

• Last revealer bias. The last participant to reveal sees everyone else’s seed and can choose whether to reveal or abort.
• Forcible abortion. If one participant fails to reveal, the protocol must either rerun or use a fallback that the attacker may control.
• Weak commit binding. If the commit is not strongly bound to identity, a participant can reveal a different seed after seeing others.

Mitigation

Use publicly verifiable commitments with slashing for non-reveal. Require a supermajority reveal threshold and use a deterministic fallback derived from the revealed seeds so that the attacker cannot game the abort path. The fallback is part of the protocol, not an afterthought.

Verifiable Delay Functions (VDFs)

A VDF guarantees that the output could not have been computed faster than a known wall-clock time, even by a massively parallel adversary. By feeding a public seed into a VDF, a protocol obtains a value that no one could have predicted before the seed was fixed.

Why VDFs help

• They eliminate the last-revealer problem because the output is determined by the seed and the sequential function, not by any participant’s choice.
• They provide a time-based firewall between prediction and outcome.
• They can be verified efficiently by any light client.

Caveats

• The VDF parameter must be calibrated to the fastest honest hardware. An attacker with custom ASICs can break the delay assumption.
• VDFs need an input seed that is itself unbiased. They do not create randomness; they delay its revelation.
• A poorly chosen VDF can be shortcut by cryptanalysis. We prefer schemes based on repeated squaring in groups of unknown order with published proof systems.

Distributed randomness beacons (DRB)

A DRB is a service that emits fresh, unpredictable randomness at fixed intervals. Examples include threshold signature schemes such as BLS-based DRBs, where t + 1 of n nodes must contribute partial signatures to produce the output.

Strengths

• No single party controls the output.
• Liveness can survive up to t faults by assumption.
• Output is compact and easy to verify on-chain.

Weaknesses

• The distributed key generation (DKG) ceremony is fragile. A single misconfigured node can force a restart, and the public transcript must be auditable.
• Threshold assumptions must be aligned with the protocol’s overall fault model. If the DRB tolerates 33% faults but the consensus tolerates 50%, the randomness layer becomes the binding bottleneck.
• Collusion among threshold members is a real risk if the same operators run both consensus and DRB nodes.

Evaluation checklist

When we review a randomness layer, we ask:

1. Is the seed generated before the attacker can influence the outcome?
2. Is the output unpredictable until the protocol needs it?
3. Can any single party abort or bias the generation?
4. Is the verification cost low enough for light clients?
5. Is the randomness used only once, or is the same output stretched across multiple decisions?

Closing note

Randomness is not a spice you add to a consensus protocol. It is a load-bearing wall. If it fails, everything built on top of it — committees, leader election, proposer ordering, sampling — fails at the same time.