BLS signature

BLS (Boneh–Lynn–Shacham) signatures excel at one extraordinary trick: thousands of separate signatures can be compressed into a single short signature that one verification check confirms. Ethereum's proof-of-stake depends on this to handle a validator set numbering in the hundreds of thousands.

BLS uses a pairing — a bilinear map e: G1 x G2 -> GT satisfying e(aP, bQ) = e(P, Q)^(ab) — on a pairing-friendly curve (Ethereum uses BLS12-381). To sign message m with secret x: hash m to a curve point H(m) and compute the signature sigma = x·H(m). To verify with public key P = xG: check e(sigma, G) == e(H(m), P). The aggregation magic: multiply many signatures together, sigma_agg = product of sigma_i, and if all signed the SAME message the whole batch verifies with one pairing check e(sigma_agg, G) == e(H(m), sum of P_i).

This is exactly why Ethereum validators attest to the same block per slot: their BLS signatures aggregate down to about 96 bytes regardless of how many signed, with a single summed public key. Signatures are deterministic — there is no per-signature nonce, so the ECDSA nonce-reuse footgun simply does not exist — and they are short. The costs: pairing operations are heavier than ECDSA or Schnorr verification, aggregating signatures over DISTINCT messages needs one pairing per distinct message, and rogue-key attacks must be blocked via proof-of-possession or message augmentation.