Skip to main content

Why ETH 2.0 uses BLS

· 3 min read
Milad

Ethereum 2.0 didn’t switch to BLS for novelty. It was a necessity.

ECDSA and Ed25519 got us far. But Ethereum 2.0 and other high-throughput chains demand more: scalable aggregation, robust threshold signing, and efficient multi-signature verification.

BLS delivers. Built on pairing-friendly curves like BLS12-381, it enables true signature aggregation, simpler threshold cryptography, and exact verification that scales with thousands of signers, without hacks or heuristics.

Where ECDSA and Ed25519 Hit Limits

  • No native aggregation: Signatures can’t be securely combined without interactive protocols or additional assumptions.
  • Threshold signing is heavy: Multi-party schemes require rounds of interaction, high bandwidth, and coordination complexity.
  • Batch verification is brittle: Ed25519 batch verification is heuristic (one invalid signature can invalidate the batch).

In validator-heavy consensus (think: 100,000+ signatures per epoch), these are dealbreakers.


What BLS Enables

  • Signature aggregation: Multiple signatures over the same message (or even distinct messages) compress into a single, compact proof.
  • Non-interactive threshold signatures: BLS supports threshold schemes with just a secret sharing setup (no rounds of communication).
  • Efficient verification: One pairing check can verify an entire aggregate. No trial-and-error. No trust in heuristics.

Real-World Adoption

  • Ethereum 2.0 (Beacon Chain): Uses BLS12-381 for validator attestations, cutting signature size and improving sync efficiency.
  • Dfinity (Internet Computer): Relies on BLS threshold signatures for its chain-key tech and scalable consensus.
  • Filecoin: Aggregates proofs and multi-party signatures using BLS to reduce on-chain overhead.
  • Chia: Employs BLS extensively for farming proofs and transaction aggregation.
  • ZK Rollups: Use BLS for attesting validator sets and compressing multi-signer operations.

If you’re building or auditing consensus, BLS isn’t optional, it’s foundational.


Trade-offs and Engineering Costs

  • Slower than ECDSA/Ed25519: Pairing operations (e.g. Miller loops, final exponentiation) are expensive. Expect ~2–10× slower verification.
  • Larger key sizes: BLS public keys are 48 bytes vs 32 bytes for Ed25519. Not huge, but non-trivial at scale.
  • Complex field arithmetic: Pairings involve extension fields (e.g., Fp12) and more attack surface. Constant-time implementation is critical.
  • Historical patent baggage: Prior schemes had licensing issues. BLS12-381 is patent-clear today, but worth noting.

These costs are real (but predictable). Libraries like blst and zkcrypto/bls12_381 make implementation practical in Rust.


The Real Impact

  • Less data on-chain: Aggregation reduces bandwidth and block size.
  • Lower verification load: One check replaces hundreds or thousands.
  • Built-in fault tolerance: Threshold signing improves resilience without extra consensus layers.

Ethereum needed cryptography that scales with its validator set. BLS wasn’t a gamble, it was the only option that met the requirements.


🔗 Further Reading