BLS Signatures and Aggregate Signature Schemes

BLS signatures rely on bilinear pairings — a mathematical operation on elliptic curves. A pairing e: G1 x G2 -> GT maps pairs of points from two groups (G1, G2) to a target group GT. The critical property is bilinearity: e(aP, bQ) = e(P, Q)^(ab) for scalars a, b and points P, Q. This allows checking relationships between group elements without knowing the discrete logarithms. The most used pairing curve for cryptography is BLS12-381, chosen for its 128-bit security level, small group element sizes (48 bytes in G1, 96 bytes in G2), and efficient pairing computation.

A BLS (Boneh-Lynn-Shacham) signature works as follows. Key generation: private key x is a random scalar; public key PK = x * G where G is the G2 generator. Signing: given message m, compute H = hash-to-curve(m) in G1, then sigma = x * H. The signature sigma is a single G1 point (48 bytes on BLS12-381). Verification: check e(sigma, G) == e(H, PK). By bilinearity, e(x*H, G) = e(H, G)^x = e(H, x*G) = e(H, PK). Security relies on the co-CDH assumption: computing x*H given H and x*G is hard without knowing x.

BLS signatures support non-interactive aggregation: given signatures sigma_1, ..., sigma_n on messages m_1, ..., m_n from public keys PK_1, ..., PK_n, an aggregator computes sigma_agg = sigma_1 + sigma_2 + ... + sigma_n (elliptic curve point addition). The aggregate signature is a single 48-byte value regardless of n. Verification requires n+1 pairing operations: check e(sigma_agg, G) == product(e(H_i, PK_i)). For the common case where all signers sign the same message, verification reduces to 2 pairings: e(sigma_agg, G) == e(H, sum(PK_i)).

Naive BLS aggregation is vulnerable to the rogue key attack. Adversary registers PK_adv = x_adv*G - PK_honest. The aggregated key PK_agg = PK_honest + PK_adv = x_adv*G, which the adversary controls entirely. Defense options: (1) Proof of Possession (PoP): each signer proves knowledge of their private key by signing their own public key during registration. (2) Message augmentation: include each signer's public key in their message. (3) Delinearization (BGLS): multiply each public key by hash(PK_i, all_PKs) before aggregation, breaking the linearity that enables the attack. Ethereum uses PoP for validator registration.

Ethereum's consensus layer (Beacon Chain) makes extensive use of BLS12-381 aggregation. Each slot, approximately 400,000+ active validators attest to the chain head. Without aggregation, storing all signatures would require ~400,000 * 96 bytes = 38 MB per slot. With BLS aggregation per committee (typically 512 validators), each committee produces one 96-byte aggregate signature, reducing total signature data to kilobytes per slot. The beacon chain block body contains aggregate attestations: a bitfield indicating which validators participated, plus one aggregate BLS signature for each committee.

BLS signature operations have different performance characteristics than ECDSA. BLS signing requires one hash-to-curve and one scalar multiplication (~1 ms on modern hardware). BLS verification requires two pairing operations (~3-5 ms each = ~6-10 ms total). ECDSA signing requires one point multiplication (~0.2 ms); verification requires two point multiplications (~0.4 ms). BLS verification is slower per-signature but far faster in aggregate: verifying 1000 BLS signatures aggregated requires ~10 ms total vs ~400 ms for 1000 individual ECDSA verifications. The crossover point is around 2-3 signatures.

Threshold BLS extends aggregation to secret sharing. In a (t, n) threshold scheme, the private key is split into n shares using Shamir secret sharing over the BLS scalar field. Each shareholder i produces a partial signature sigma_i = sk_i * H(m). Any t partial signatures can be combined using Lagrange interpolation coefficients: sigma = sum(lambda_i * sigma_i). The result is identical to the signature produced by the original key, but no single party ever holds the complete key. Threshold BLS is used in distributed validator technology (DVT), MPC wallets, and threshold signing services like Fireblocks and Web3Auth.

Filecoin uses BLS signatures for its storage proof system and transaction signing. Storage miners aggregate multiple proofs using BLS aggregation, reducing on-chain verification costs. Filecoin's message pool also aggregates multiple transaction signatures into a single aggregate, reducing block sizes. The Filecoin implementation uses the IETF BLS draft standard (hash-to-curve per RFC 9380, BLS12-381 curve) with minimum-pubkey-size variant where public keys are in G1 (48 bytes) and signatures in G2 (96 bytes) — the opposite of Ethereum's convention.

While Zcash primarily uses Groth16 zk-SNARK proofs, BLS pairings are the foundation of many pairing-based zero-knowledge constructions. The Groth16 verification equation is a pairing check: e(A, B) = e(alpha, beta) * e(vk, C) where A, B, C are proof elements. KZG polynomial commitments (used in Ethereum's EIP-4844 blob transactions and various ZK rollup systems) also rely on BLS12-381 pairings: a commitment to polynomial f(x) is C = f(tau)*G, and evaluation proofs are pairing-verified. BLS12-381 was specifically chosen for its efficient pairing operations and 128-bit security.

BLS is not the only aggregatable signature scheme. Schnorr signatures support key aggregation (MuSig2, used in Bitcoin Taproot) where multiple signers produce a single Schnorr signature indistinguishable from a single-signer signature. FROST (Flexible Round-Optimized Schnorr Threshold) provides threshold Schnorr signatures in two rounds. However, Schnorr aggregation requires interaction between signers (unlike BLS non-interactive aggregation), making it less suitable for large validator sets. BLS remains preferred for blockchain consensus due to its non-interactive aggregation and efficient batch verification.

BLS signatures are based on elliptic curve pairings, which are vulnerable to quantum computers running Shor's algorithm. A sufficiently powerful quantum computer could compute discrete logarithms in BLS12-381, breaking all existing BLS signatures and defeating Ethereum's consensus security. The timeline is uncertain but NIST estimates 15-20 years for cryptographically relevant quantum computers. Ethereum and other BLS-dependent chains will need to migrate to post-quantum signature schemes (CRYSTALS-Dilithium/ML-DSA or SPHINCS+/SLH-DSA) before this threat materializes. The migration requires protocol-level changes to validator registration, attestation formats, and aggregate verification.

What is the primary advantage of BLS signature aggregation in Ethereum's consensus layer?

BLS signatures use bilinear pairings on BLS12-381 curves. Signatures are 48-byte G1 points; public keys are 96-byte G2 points in Ethereum's convention. Non-interactive aggregation combines n signatures into one 48-byte value, verified with n+1 pairings. The rogue key attack is mitigated by Proof of Possession during validator registration. Ethereum uses BLS to compress 400,000+ validator attestations per slot into kilobytes. Threshold BLS enables distributed validators with no single key holder. BLS is pairing-based and not post-quantum secure, requiring future migration.