Our Consensus Collapses a Whole Committee's Votes Into One Signature, and That Committee Is Four Machines We Operate

The mechanism described below is implemented and running; the committee size it exists for is not what is running.

The problem aggregation solves

A block is final when enough validators have voted for it. The naive way to prove that is to carry every vote: one signature per validator, attached to the block, kept forever.

That does not scale. A committee of a hundred means a hundred signatures on every block, stored by every node, checked by every client, for the life of the chain.

Aggregation makes the proof a fixed size. Many signatures on the same message collapse into one that is exactly as large as a single signature and still verifies against all the signers' keys at once. A block then carries that one signature plus a bitmap of who is included. Five voters or five hundred, the certificate is the same size.

This is the default in most modern Byzantine-fault-tolerant consensus designs, and choosing it is not a claim to originality.

What we actually run

The design targets a committee of 21-of-100 validators, elected by verifiable random function. That is a spec. The running network is four validators, operated by one party, which is us.

But four signatures becoming one demonstrates that the code path works, not the property that makes aggregation worth having, because carrying four signatures separately would have been fine.

So the mechanism is built and the conditions that justify it are absent. Those are two different claims, and projects in our position blur them constantly.

What sharing one curve costs us

The vote aggregation and our selective-disclosure work stand on the same pairing-friendly curve.

That is one mathematical assumption underneath two features that look unrelated on an architecture diagram. A serious weakening of it would move consensus efficiency and the privacy property together. It is a well-chosen assumption with sustained academic attention, and we are more concentrated on it than a system with four unrelated foundations would be. The full accounting is on the pairing-based cryptography page, including the part where published estimates for this family have moved before.

What to ask any chain about its committee

"What committee is running, as opposed to specified?" The two numbers appear in different documents at almost every project, and only one of them is a fact. For us the running number is 4 validators; 21-of-100 is the spec and is not deployed.

"Who operates the validators?" Aggregation across machines a single party controls proves the arithmetic and nothing about decentralisation. For us that party is us.

"Has the consensus code been independently audited?" For us: no. Consensus bugs are the expensive kind, because they surface as forks rather than as error messages.

"What else in your system rests on the same curve?" Most vendors have never counted, and the answer is rarely visible on the diagram.

Where this leaves a decision

If you need a validator set that is not operated by the vendor, we do not have one today, and no amount of correct cryptography inside our four validators, which share one process, substitutes for it.

If you are evaluating whether the engineering underneath is real, the aggregation is implemented, the algorithm above it is model-checked, one result has been reproduced by a stranger from a clean clone, and the committee that would make any of it matter is a design rather than a deployment.