Cryptoeconomic signature aggregation



TLDR: We present a signature aggregation scheme intended as a possible alternative to BLS signatures in the context of committee voting, with applications such as committee-based notorisation and fork-free sharding.


Let V be a committee of voters v_1, ..., v_n. For a given message m every voter can cast one vote by signing m. For concreteness we set |V| = 423 (as inspired by Dfinity) and require a threshold of t votes (e.g. t = |V|/2) to form a quorum.

Given at least t votes, some collateralised claimer (e.g. an eligible proposer, blockmaker or collator) can aggregate the votes by creating a bitstring B=\{b_i\} of size 423 bits, where b_i=1 represents a claim that v_i signed m, and b_i=0 otherwise. The claimer signs [m, B] to form a signature s. The cryptoeconomic aggregated signature is [m, B, s].

During some challenge period anyone can challenge the claimer to provide the signature of m from v_i if the bit b_i is set to 1. Failure to provide the signature in time slashes half the claimer’s collateral, and rewards the other half to the challenger.


The overhead of the aggregation scheme is 423 bits (53 bytes). Every voter (e.g. a notary, collator, validator) knows whenever the claimer is reporting a false vote from himself, so it is risk-free for the voter to challenge the claimer.

Compared to BLS signatures, the aggregation scheme does not require a setup phase among the voters. The scheme is also quantum secure if s and the votes (signatures of m) are quantum secure.

Another way of understanding what cryptoeconomic aggregated signatures do
Cryptoeconomic aggregate signatures for the main chain
Plasma XT: Plasma Cash with much less per-user data checking
Offchain collation headers
Pragmatic signature aggregation with BLS

Well this provides more details compared to the bitfield in A general framework of overhead and finality time in sharding, and a proposal. What are other pros and cons compared to other signature schemes, e.g. performance?


This is different from the bitfield in that post. In that post, all signatures are directly on chain, but each signature serves to notarize many objects (eg. 200) simultaneously; the bitfield’s function is that it’s the protocol that selects which 200 things the notary needs to sign, but the notary may not approve of all 200 of them, so through the bitfield the notary can specify which of the 200 they approve.

Here, the bitfield is a bitfield of which underlying signatures are present (as opposed to which underlying messages are approved).


The bitfields are different. This one is regarding voters and votes (one bit corresponds to a voter, and the knowledge of a vote), whereas the other is regarding proposals (one bit corresponds to a proposal header, and the availability of the proposal body).

The key goal of aggregation is succinctness, which has been achieved. The main disadvantage is that we have an interactive game so “validating” the aggregated signature takes time. Also, we need an “eligible” claimer to put down collateral and make the claim. The advantages compared to BLS are 1) no setup and 2) quantum secure.


I have a few concerns with actually using this in practice:

  • Unless the deposit associated with this signature is extraordinarily large, there will be cases where a signature gets into the main chain despite actually being incorrect. If coupled with a main chain availability failure (eg. censorship), this could lead to a bad collation getting internally finalized more easily.
  • The cryptoeconomic signature doesn’t reveal each notary’s auxiliary data for any availability challenge / proof of custody mechanics.

I suppose we could require some kind of secondary committee to sign off on all the cryptoeconomic signatures and attest to their availability, but that does add its own complexity…


Are there cases where someone benefits if voter v_{x} doesn’t sign off on the proposal but the claimer states that b_{x} = 1? i.e. if b_{x} = 1 is accepted into the root chain then v_{x} has effectively signed off on the proposal by not challenging. I do see a potential problem if only the claimer knows that v_{x} is offline and will not challenge. Otherwise it seems like (as long as deposit covers cost of challenging) it’s economical that v_{x} either challenges or the outcome of the vote is more beneficial than the return of the deposit.

So unlike BLS where an offline voter will always vote “no,” an offline voter in this system may vote “yes” depending on the distribution of information.


Are there cases where someone benefits if voter v_x doesn’t sign off on the proposal but the claimer states that b_x = 1?

Yes, that’s absolutely possible. And yes, voter v_x could potentially never challenge (though a third party could).


Consider that a voter may “bluff” being offline for some time (say by being inactive for 1 month) to encourage fake yes votes and “trap” cheating claimers, My intuition is that trapping risk is enough of a deterrent to keep rational claimers honest.


Would there be any incentives for a claimer to ignore a voter’s vote? Like preventing the voter from getting reward?
And is there a way for voter to challenge if it happens? Seems to me there’s no way to distinguish a vote being ignored and a vote that’s only signed after?


Are there any reasons for a third party to challenge a vote? If the voter is offline, how would a third party be able to decide to challenge a claim for that voter? (Assuming there is a fee associated with a challenge, every vote may as well be published as it is rational to challenge every bit in the counterfactual.)