BLS signature aggregation: what it saves and what it costs

BLS signatures on the BLS12-381 curve let a hundred validators sign a block and ship one signature. That is why consensus protocols like them. The savings are real, and so are the ways to get it wrong.

What aggregation saves

A BLS signature is a single curve point. Signatures from different signers add up into one point of the same size, and when everyone signed the same message the public keys add up too. Verifying the whole set then costs two pairings plus one point addition per signer. The additions are cheap, so verification time grows only slowly with the size of the committee, and the message carries one signature plus a bitmap of who signed.

What verification costs

A pairing is the expensive operation, and verifying one signature takes two of them. On a modern laptop that is around a millisecond, far slower than an Ed25519 check. Aggregation pays off when it replaces many verifications with one; for a single signature, BLS is the slower choice.

Rogue keys

If public keys are simply added, an attacker can register a key crafted to cancel out the honest ones and forge an aggregate signature alone. The standard defence is a proof of possession: every key is registered together with a signature over itself, using a separate domain separation tag, proving the owner holds the secret. Message augmentation, signing the public key together with the message, also stops rogue keys, but it makes every signed message distinct, so you lose the two-pairing check above. Key aggregation with per-key coefficients, as in BDN, keeps the cheap check without proofs of possession, at the cost of one scalar multiplication per signer.

Subgroup checks

BLS12-381 points must lie in the prime-order subgroup, and the identity point must be rejected as a public key. Points from outside the subgroup can break security assumptions in subtle ways. Every key and signature that arrives over the network needs a subgroup check before it is used, and the check has a cost you should measure rather than skip.

Keys in G1 or G2

BLS12-381 has two groups, and a protocol has to choose which one holds the keys. With keys in G1, a public key is 48 bytes and a signature 96 bytes; the IETF draft calls this the minimal-pubkey-size variant, and Ethereum's consensus layer uses it. The other way round, signatures are 48 bytes and keys 96. Small keys suit large validator sets that aggregate keys every round; small signatures suit systems that store or send many of them.

Either way, messages are mapped to the curve with the hash-to-curve method of RFC 9380. Use a library that implements it rather than a home-made map.

Distinct messages

When signers sign different messages, verification needs one pairing per distinct message plus one. Aggregation still saves bandwidth, but verification time grows again. Protocols that want the cheap case make validators sign the same message.

Where we'd start

Use proofs of possession for every registered key, with their own domain separation tag.
Run subgroup checks on every key and signature from the network, reject the identity as a public key, and cache the result per key.
Design the protocol so that signers in one round sign the same message.
Benchmark verification on your validators' hardware, not on a laptop.