Leader Election

Origin: composes, VRF-based sortition popularized by Algorand (2017), reimplemented from scratch, not borrowed code. Solidus status: testnet, live every round; nearly indistinguishable from Committee Election at today's small scale.

Leader election is how a blockchain decides, for one specific round, which single validator gets to propose the next block. It's a narrower question than Committee Election, deciding the pool of validators eligible to participate at all, even though the two are easy to conflate, and at small network sizes they can look identical. A good leader-election scheme needs two properties in tension: it has to be unpredictable enough that an attacker can't know in advance who to target or bribe, and it has to be verifiable after the fact, so everyone else can confirm the winner really was chosen fairly rather than picked by whoever happened to speak first.

A common way to get both is a Verifiable Random Function (VRF): each eligible validator computes a value from their own private key and a shared, unpredictable seed (typically derived from the previous round). The result determines who wins, often "whoever computed the lowest output", and because it's a VRF rather than plain randomness, anyone can later verify the proof and confirm the winner didn't cheat, without being able to have predicted the outcome beforehand.

Where it comes from

This specific approach, VRF-based, individually-computed, publicly-verifiable leader selection, was popularized by Algorand's 2017 "cryptographic sortition" design, published by Yossi Gilad, Rotem Hemo, Silvio Micali, Georgios Vlachos, and Nickolai Zeldovich. Similar VRF-based approaches appear across proof-of-stake protocols since. Solidus composes the general technique; the actual implementation in solidus-consensus's leader.rs, the file's own header names it "VRF-based leader election for the Solidus consensus engine", is a from-scratch Ed25519 VRF, not adapted from Algorand's or any other project's code.

How it works in Solidus's engine

Each validator computes input = BLAKE3(round_seed || round), where the seed comes from the previous round's VRF output (or a genesis seed at the very start), guaranteeing every round has a fresh, unpredictable input even if nothing else about the state changes. Each validator runs this input through its own Ed25519-based VRF to produce an output and a proof; the validator whose output decodes to the lowest u64 value wins the round and becomes the block proposer. Any other validator can independently verify the claimed winner's proof against their public key and the same round input, confirming the result without having to trust it.

Committee Election vs. Leader Election, at Solidus's current scale

It's worth naming the overlap plainly rather than letting it blur. The target protocol design separates two distinct steps: first elect a 21-validator active committee from a larger eligible pool (see Committee Election), then use leader election to choose one proposer from within that already-elected committee each round. On the live testnet, with exactly four total validators, there's no larger pool to select a subset from, every validator is in the committee every round, so "committee election" is nearly vacuous at this scale and the VRF mechanism described here is doing effectively all of the visible work, every round, by itself.

Check it yourself

The leader-election function and its verification logic are visible in source in the public solidusnetwork/protocol repository's solidus-consensus crate, no running node required to confirm the mechanism exists exactly as described.

Related terms: Committee Election · View Change · Quorum Certificate · HotStuff · VRF · Ed25519/EdDSA