BLS Signature

What Is a BLS Signature?

A BLS signature (Boneh-Lynn-Shacham) is a cryptographic digital signature scheme built on bilinear pairings over elliptic curves. Introduced by Dan Boneh, Ben Lynn, and Hovav Shacham in 2001, the scheme produces short, deterministic signatures that can be aggregated: any number of BLS signatures on any number of messages can be combined into one signature that proves all original signers authenticated their respective messages.

This aggregation property is what sets BLS apart from other signature schemes. With Schnorr signatures, producing a combined multisignature requires multiple communication rounds between signers (as in MuSig2). BLS aggregation is non-interactive: given a collection of individual signatures, anyone can combine them after the fact without any participation from the original signers.

This property made BLS the natural choice for Ethereum's Beacon Chain, where thousands of validators must attest to blocks every 12-second slot. Without aggregation, the network would need to transmit and verify each attestation individually, creating an impossible bandwidth and computation bottleneck.

How It Works

BLS signatures rely on a mathematical tool called a bilinear pairing: a function that takes two points from elliptic curve groups and maps them to an element in a target group, preserving certain algebraic relationships. This pairing is what enables both compact signatures and non-interactive aggregation.

Key Generation

A signer generates a private key (a random scalar) and derives a public key by multiplying a generator point on the elliptic curve by that scalar. On the BLS12-381 curve used by Ethereum, private keys are 32 bytes.

// Key generation (conceptual)
private_key = random_scalar()           // 32 bytes
public_key  = private_key * G2          // point on curve G2 (96 bytes)
// G2 is a generator of the second elliptic curve group

Signing

To sign a message, the signer hashes the message onto a point on the first elliptic curve group (G1) and multiplies that point by the private key. The result is the signature: a single curve point.

// Signing
hash_point = hash_to_curve(message)     // map message to G1 point
signature  = private_key * hash_point   // G1 point (48 bytes)

Unlike ECDSA, BLS signing is deterministic: the same private key and message always produce the same signature. There is no random nonce involved, which eliminates an entire class of vulnerabilities related to nonce reuse.

Verification

Verification uses the bilinear pairing to check that the signature is valid without knowing the private key. The verifier checks that the pairing of the signature with the G2 generator equals the pairing of the hashed message with the public key:

// Verification check
e(signature, G2) == e(hash_to_curve(message), public_key)

// This works because:
// e(sk * H(m), G2) == e(H(m), sk * G2)
// The bilinear property lets the secret key "move"
// between the two inputs of the pairing function

The pairing computation is the expensive step: it involves complex field arithmetic that makes BLS verification roughly ten times slower than Schnorr or ECDSA verification for a single signature.

Aggregation

The defining feature of BLS is aggregation. Given multiple signatures on the same message (or different messages), anyone can combine them:

// Same-message aggregation (e.g., validator attestations)
agg_signature = sig_1 + sig_2 + ... + sig_n   // point addition
agg_pubkey    = pk_1 + pk_2 + ... + pk_n       // point addition

// Verify all n signatures with a single pairing check
e(agg_signature, G2) == e(hash_to_curve(message), agg_pubkey)

This is purely additive: signatures and public keys are elliptic curve points, and combining them is just point addition. No interaction between signers is required. The aggregated signature is the same size as an individual one (48 bytes on BLS12-381), regardless of how many signatures were combined.

The BLS12-381 Curve

Most modern BLS implementations use the BLS12-381 curve, a pairing-friendly elliptic curve designed specifically for this purpose. It provides approximately 128 bits of security and defines two curve groups (G1 and G2) plus a target group (GT) for the pairing output.

The choice of which group holds signatures versus public keys is a design decision. Ethereum places signatures in G1 (48 bytes) and public keys in G2 (96 bytes), optimizing for smaller aggregated signatures at the cost of larger public keys.

BLS vs. Schnorr Signatures

Both BLS and Schnorr support some form of signature aggregation, but they make fundamentally different trade-offs. Bitcoin adopted Schnorr via BIP-340, while Ethereum chose BLS for its consensus layer.

For large validator sets like Ethereum's (hundreds of thousands of validators), BLS's non-interactive aggregation is essential: coordinating interactive signing rounds among that many participants per slot would be impractical. For Bitcoin's use case of small multisig groups (typically 2-of-3 or 3-of-5), Schnorr's interactive MuSig2 protocol works well and avoids the overhead of pairing-based cryptography. For more details, see the Taproot and Schnorr deep dive.

Use Cases

Ethereum Validator Attestations

The largest deployment of BLS signatures today is Ethereum's Beacon Chain. Each slot (12 seconds), thousands of validators attest to the current chain head. The network organizes validators into committees, selects aggregators within each committee, and uses BLS aggregation to compress hundreds of attestation signatures into a single aggregated signature per committee.

Without BLS aggregation, each block would need to include and verify individual signatures from every attesting validator, consuming enormous bandwidth and computation. With aggregation, the block proposer includes a handful of aggregate signatures plus bitmaps indicating which validators participated, keeping block sizes manageable even with over one million active validators.

Threshold Signatures

BLS naturally supports threshold signatures, where any t-of-n participants can produce a valid signature. Each participant holds a key share derived via distributed key generation, signs independently, and the partial signatures are combined. The resulting signature is indistinguishable from a single-signer BLS signature.

This property is used in protocols like FROST (which adapts threshold signing for Schnorr) and in various bridge designs that use BLS threshold committees to attest to cross-chain state. For a deeper comparison of threshold schemes, see the FROST threshold signatures explainer.

Zero-Knowledge Proofs

The BLS12-381 curve is not only used for signatures. It is the most widely adopted curve for zero-knowledge proof systems, including zk-SNARKs. The same pairing-friendly properties that enable BLS signature aggregation also make the curve suitable for constructing proof systems used in zk-rollups and privacy protocols.

Multi-Chain Consensus

Beyond Ethereum, BLS signatures are used in several blockchain consensus protocols. Chia Network uses BLS for all transaction signatures, Filecoin uses BLS for block signing, and various proof-of-stake chains leverage BLS aggregation to scale their validator sets without proportionally increasing verification costs.

Risks and Considerations

Rogue Key Attacks

Naive BLS aggregation is vulnerable to rogue key attacks: an adversary can craft a malicious public key that, when aggregated with honest participants' keys, produces a forged aggregate signature. The attacker computes their "public key" as a function of the victims' keys, effectively canceling out their contributions and forging the aggregate.

The standard mitigation is proof of possession (PoP): each participant must prove they know the private key corresponding to their public key by signing a specific message (typically the public key itself) during registration. Ethereum's validator deposit process requires this proof. An alternative defense is the "message augmentation" scheme defined in the IETF BLS specification, which appends the signer's public key to the message before hashing.

Pairing-Based Security Assumptions

BLS security rests on the computational Diffie-Hellman assumption in pairing groups, a stronger (less conservative) assumption than the discrete logarithm assumption underlying Schnorr and ECDSA. If pairing-based assumptions were broken without breaking discrete log, BLS would fail while Schnorr would survive. In practice, both assumptions have held for decades, but the distinction matters for post-quantum cryptography planning: both are vulnerable to quantum computers running Shor's algorithm.

Verification Performance

Individual BLS signature verification is significantly slower than Schnorr or ECDSA due to the cost of computing pairings. This makes BLS less suitable for systems that primarily verify individual signatures (like Bitcoin transaction validation) and most valuable where aggregation amortizes the pairing cost across many signers.

For Ethereum, the trade-off is clearly positive: verifying one aggregated signature for an entire committee is far cheaper than verifying hundreds of individual Schnorr signatures. For systems like Bitcoin or Spark, where transactions typically involve small signer sets, the faster single-signature verification of Schnorr is preferred.

Implementation Complexity

Pairing-based cryptography is more complex to implement correctly than standard elliptic curve operations. The BLS12-381 curve arithmetic involves extension fields (field towers up to degree 12), making implementations larger and harder to audit. Side-channel resistance is also more challenging to achieve in pairing computations than in scalar multiplication alone.

This glossary entry is for informational purposes only and does not constitute financial or investment advice. Always do your own research before using any protocol or technology.