Skip to content
Financial Context Wiki

BLS Signatures

A verification-focused guide to Boneh-Lynn-Shacham signatures, aggregation modes, ciphersuites, rogue-key defenses, Ethereum consensus use and implementation risk.

Updated

For educational purposes only; not investment or cryptographic implementation advice. Signature validity does not by itself prove protocol safety, authorization, availability, or finality.

Direct answer

A Boneh-Lynn-Shacham signature is a pairing-based digital signature. In a common orientation, secret key sk produces public key PK = sk * G1; message m is mapped to H(m) in G2; and signature sig = sk * H(m) verifies through e(PK, H(m)) = e(G1, sig). Exact groups, encodings, hash-to-curve suite and domain separation are ciphersuite choices, not interchangeable notation.

BLS has an unusual operational advantage: valid signatures can be added into one constant-size group element. That compresses signatures, but it does not compress the signer list, prove quorum, identify authorized validators, prevent equivocation or make consensus final. Those properties come from the surrounding protocol.

How it works

  1. Pin the protocol, ciphersuite and version: curve, public-key and signature groups, serialization, hash-to-curve function, domain-separation tag and message-root construction. Never infer compatibility from the label BLS alone.
  2. Generate sk with the specified key-generation procedure and derive PK. Reject zero, infinity, malformed, noncanonical and wrong-subgroup encodings through the exact KeyValidate and deserialization rules.
  3. Construct the exact message bytes and signing domain. In Ethereum consensus, the signing root binds an SSZ object root to a domain derived from operation type and fork data; display text is not the signed object.
  4. Sign and individually verify with the selected scheme. The Basic, message-augmentation and proof-of-possession variants have different rogue-key defenses and cannot be mixed casually.
  5. Choose the aggregate verifier by message pattern. Use FastAggregateVerify only for multiple validated public keys signing the same message under the required proof-of-possession assumptions; use AggregateVerify for the scheme’s permitted public-key and message list.
  6. Reconstruct the signer set independently from committee data or a participant bitlist, reject duplicate or unauthorized indices, apply stake or threshold weights, and then verify the aggregate signature. A valid aggregate authenticates the supplied set; it does not decide whether that set meets policy.
  7. Reconcile the result with fork choice, slashing conditions, quorum, availability, timing and finality. Preserve input bytes, domains, signer indices, implementation version and test vectors, and compare independent libraries before deployment.

Worked examples

  • Compression does not remove membership data. Ethereum consensus encodes each BLS public key as 48 bytes and each signature as 96 bytes. For 512 same-message signatures, separate signatures occupy 512 * 96 = 49,152 bytes. One aggregate signature plus a 512-bit = 64-byte participant bitlist occupies 96 + 64 = 160 bytes, a reduction of 49,152 - 160 = 48,992 bytes, or 99.6744791667%. The validator public keys and committee mapping must still be available elsewhere.
  • Same-message aggregation. Suppose registered validators 17, 24, and 91 all sign the identical signing root R. Their signatures aggregate as sigAgg = sig17 + sig24 + sig91. Verification uses the ordered, validated public-key set [PK17, PK24, PK91], the same R, and FastAggregateVerify. A valid result proves those keys signed R under the scheme; a separate rule decides their weight and whether three signers form a quorum.
  • Distinct messages need the correct API. Keys PK1, PK2, and PK3 sign distinct messages m1, m2, and m3. The verifier must preserve the pairing [PK1, m1], [PK2, m2], [PK3, m3] and call the applicable AggregateVerify; replacing those inputs with one message and FastAggregateVerify verifies a different claim. Under the Basic scheme, the messages must also be distinct.
  • Aggregation is not threshold signing. In an 8-member group, ordinary aggregation of signatures from members [1, 2, 4, 6, 8] produces one signature plus a five-member signer list. It does not become a 5-of-8 threshold signature under one group public key. A true threshold-BLS design needs a distributed key-generation or trusted-dealer model, share indices and interpolation rules; its trust and failure assumptions must be audited separately.

Risks

  • Using a curve, group orientation or ciphersuite that differs from the protocol.
  • Signing different serialized bytes despite displaying the same human-readable message.
  • Omitting the fork, operation or application domain and enabling cross-context replay.
  • Treating an expired Internet-Draft as an immutable final standard.
  • Accepting malformed, noncanonical or infinity point encodings.
  • Skipping subgroup checks and admitting invalid-curve or small-subgroup inputs.
  • Using ad hoc hash-to-curve code instead of the specified suite and test vectors.
  • Generating biased, zero, duplicated, leaked or predictably derived secret keys.
  • Reusing one key across protocols whose proof-of-possession and domain assumptions differ.
  • Aggregating unregistered public keys without the scheme’s required rogue-key defense.
  • Calling same-message fast verification for distinct messages or inconsistent roots.
  • Permuting, duplicating or omitting the public-key-to-message association.
  • Trusting a participant bitlist without checking committee membership and unique indices.
  • Counting signatures rather than protocol-defined stake, weight or threshold.
  • Assuming one aggregate reveals which individual signature was invalid.
  • Confusing ordinary aggregation, multisignatures and threshold signatures.
  • Treating signature validity as proof of data availability, execution correctness or finality.
  • Ignoring equivocation, slashable messages, timing windows or fork-choice context.
  • Relying on one library, CPU feature or unchecked batch-verification optimization.
  • Underestimating pairing cost, denial-of-service inputs, side channels, key custody, upgrades and the lack of post-quantum security.

Common misconceptions

  • An aggregate signature proves that every validator participated.
  • Any BLS public keys and signatures can be combined safely without proof-of-possession rules.
  • Constant-size aggregation removes the need to transmit or reconstruct signer membership.
  • BLS aggregation and threshold BLS are the same construction.
  • A valid BLS signature makes the signed block, bridge message or protocol economically safe and final.

Sources

Navigation

Search the wiki...