# BLS Signatures Explained

Ethereum has over 500,000 active validators. Every 1 epoch or 32 slots (~6.4 minutes), each one signs an attestation, a vote on what the chain looks like. That’s roughly 1,300 signatures per second hitting the network.

If each signature had to be verified individually, the beacon chain would choke. The bandwidth alone would be absurd. Early Casper designs (EIP-1011) topped out at around 900 validators before things fell apart.

So what changed? BLS signatures. Specifically, their ability to compress thousands of signatures into one.

What are BLS signatures?

BLS stands for Boneh-Lynn-Shacham, after the three Stanford cryptographers who published the scheme in 2001 (formally in the Journal of Cryptography in 2004). The original paper was titled “Short Signatures from the Weil Pairing”, already hinting at the key ingredient.

At a high level, BLS is a digital signature scheme like ECDSA or Schnorr. You have a private key, you sign messages, others verify with your public key. But BLS has a trick that neither ECDSA nor Schnorr can match cleanly: non-interactive signature aggregation. Take a thousand signatures from a thousand different signers and combine them into a single signature. No coordination between signers required. A third party can do the aggregation after the fact.

That one property is why Ethereum went from supporting ~900 validators to 500,000+.

The math

BLS relies on bilinear pairings, a special kind of function on elliptic curves. I took some time to wrap my head around it and I’ll distill it as much as possible.

Bilinear pairings

A pairing is a function $e: G_1 \times G_2 \rightarrow G_T$ that takes two elliptic curve points and maps them to an element in a target group. The magic property:

$e(aP, bQ) = e(P, Q)^{ab}$

You can “pull out” scalar multipliers ($a$ and $b$) and they end up as exponents in the target group. This lets you check relationships between curve points without knowing the underlying scalars.

Key generation

• Pick a random secret key $sk$ (a 32-byte integer)
• Compute the public key: $pk = sk \cdot g_1$, where $g_1$ is a generator point in $G_1$

Signing a message

Hash the message to a curve point ($H(m)$), then multiply by the secret key ($sk$):

$sig = sk \cdot H(m)$

That’s it. One multiplication. You don’t need a random nonce. BLS signatures are fully deterministic. Same key and message always produce the same signature.

Verifying a signature

The verifier checks that pairing the signature with the generator point produces the same target group element as pairing the message hash with the public key:

$e(g_1, sig) \stackrel{?}{=} e(pk, H(m))$

Why does this work? Expand both sides using the bilinear property:

• Left: $e(g_1, sk \cdot H(m)) = e(G, H(m))^{sk}$
• Right: $e(sk \cdot g_1, H(m)) = e(G, H(m))^{sk}$

They’re equal. If the signature was produced with the correct secret key, the pairing check passes.

Signature aggregation

Given $n$ signatures $sig_1, sig_2, \ldots, sig_n$ from different signers, you compute:

$sig_{agg} = sig_1 + sig_2 + \cdots + sig_n$

Just elliptic curve point addition. Cheap. And the result is the same size as a single signature (48 or 96 bytes), regardless of whether you aggregated 10 or 10,000 signatures.

To verify an aggregate of $n$ signatures on $n$ different messages:

$e(G, sig_{agg}) \stackrel{?}{=} e(pk_1, H(m_1)) \cdot e(pk_2, H(m_2)) \cdots e(pk_n, H(m_n))$

This needs $n + 1$ pairing operations, so verification doesn’t get cheaper. But the on-chain footprint is tiny: one 48-byte signature instead of $n$.

The fast case: same message

When everyone signs the same message (exactly what happens when validators in a committee attest to the same block) you can also aggregate the public keys:

$pk_{agg} = pk_1 + pk_2 + \cdots + pk_n$

Now verification is just two pairings plus some cheap point additions:

$e(G, sig_{agg}) \stackrel{?}{=} e(pk_{agg}, H(m))$

Two pairings. Whether 10 validators signed or 10,000. This is why Ethereum’s beacon chain actually works.

Why not Schnorr?

Schnorr signatures can do multisig, but it takes three rounds of interactive communication between all signers. Everyone has to be online, exchange nonce commitments, exchange nonces, then exchange partial signatures.

BLS aggregation needs zero interaction. Someone collects the signatures and adds them together. That’s it.

BLS vs ECDSA vs Schnorr comparison

The single verify speed gap is real. A BLS pairing operation is roughly an order of magnitude slower than an ECDSA verification. For applications that check one signature at a time, BLS is strictly worse.

But the aggregation economics flip everything. Dash ran benchmarks on 1,000 signature blocks: naive BLS took ~482ms vs ECDSA’s ~60ms. With pre-aggregation and mempool caching (90% of sigs already seen), BLS dropped to ~25ms. Aggregation turns a slow primitive into a fast system.

Where BLS is used today

Ethereum’s beacon chain is the most visible deployment, but BLS shows up in a few other places. Chia uses BLS as its only signature scheme (they went all in, no ECDSA fallback). Cloudflare’s randomness beacon, drand, runs threshold BLS across a distributed set of nodes to produce publicly verifiable randomness that no single participant can bias. Filecoin and Dfinity both use BLS for block signing and consensus.

The threshold use case is worth expanding on. BLS naturally supports $t$-of-$n$ threshold signing via Shamir’s secret sharing: split the secret key into $n$ shares using polynomial interpolation, and any $t + 1$ participants can produce partial signatures that combine (via Lagrange interpolation) into a valid full signature. The combined signature is indistinguishable from one produced by a single signer.

Uniqueness

BLS signatures have a property that ECDSA doesn’t: uniqueness. For a given key pair and message, there is exactly one valid signature. ECDSA produces different valid signatures depending on which random nonce you pick.

This uniqueness makes BLS useful for Verifiable Random Functions (VRFs). You can derive pseudorandom outputs from signatures, and anyone can verify the output was computed correctly. No one can grind for a favorable result.

Further reading

• Original BLS paper (Boneh, Lynn, Shacham)
• IETF BLS Signature Draft
• BLS12-381 For The Rest Of Us (Ben Edgington)
• Upgrading Ethereum: BLS Signatures