R-210 — Quorum aggregation: BLS vs Schnorr-MuSig vs sequential Ed25519 tradeoffs

R-210 — Quorum aggregation: BLS vs Schnorr-MuSig vs sequential Ed25519 tradeoffs

Task. Compare candidate signature-aggregation schemes for HERALD's quorum and threshold-attestation primitives. Recommend an admission path for the signature-suite registry.

Question framed by EXT. "EXT does not specify how members coordinate to produce co-signatures (BLS, Schnorr-MuSig, sequential Ed25519, off-chain orchestration); it specifies that the result must be expressible as multi-signature envelopes verifiable under the suite registry." — [EXT §7.4], lines 557–559.

0. The question, precisely

HERALD has two distinct N-of-M signing surfaces. Both are explicitly multi-party but neither has a chosen aggregation primitive in v0.2:

1. Threshold lineage attestation — N independent Heralds co-sign the same (subject, parent | model_hash) tuple, governed by a diversity_policy. [EXT §3.3], lines 230–247. The list shape today is concatenated: signatures: [{ "by": "<herald-sigil>", "sig": "..." }, ...].
2. Quorum attestation / collective acting — a collective sigil's statement is valid iff ≥ threshold member sigils have co-signed it under [EXT §6] multi-signature rules. [EXT §7.4], lines 538–559.

[EXT §6.6] (lines 458–462) registers only ed25519 for v0.2 and explicitly notes that "adding new suites (post-quantum candidates, Schnorr variants, BLS for aggregation) is a registry-update process". [THREATS] line 374 records the open issue verbatim:

Quorum semantics (n-of-m? threshold? aggregated BLS? concatenated Ed25519?) are not specified in v0.1 $$01-security S6$$; they must be specified before quorum is enabled.

This report answers what would actually go into that registry update.

The decision is also non-trivially constrained by [SPEC §3.4] / [SPEC §3.6] / [EXT §6.3], which require:

• The origin signature is ordinary Ed25519 over dom_sep || canonical_body. [SPEC §3.6], line 208.
• Each non-origin signature is computed over the envelope with signatures replaced by all prior signatures in declaration order. [SPEC §3.4], line 187; [EXT §6.4], line 446.
• "The same signer MUST NOT appear twice in signatures[]." [SPEC §3.4], line 188.
• "Verifiers MUST validate signatures in array order." [SPEC §3.4], line 189; [EXT §6.2], line 428.
• Domain separation per scope is mandatory; suites are role-bound. [EXT §6.3], lines 432–442.
• "Verifiers MUST reject envelopes carrying signatures with alg values not in the registry." [EXT §6.6], line 460.

These constraints shape the answer. In particular: the origin signature must remain Ed25519 (the from sigil's long-term key). Any aggregation scheme is at best a replacement for the co-signature list, not for the originator binding.

1. Candidate schemes

1.1 Sequential Ed25519 (status quo)

Each member signs independently over the progressive-signing canonical input ([EXT §6.4]). The envelope's signatures[] array carries N concrete {by, sig} pairs. Verification iterates the array in order.

This is what [SPEC §3.4] / [EXT §6] describe today. It is not "an aggregation scheme" in the formal sense — it is a list. We include it as the baseline because it is what HERALD already has, and any alternative must justify itself against it.

1.2 BLS12-381 signature aggregation (BLS)

Boneh–Lynn–Shacham over the BLS12-381 pairing-friendly curve (IETF draft draft-irtf-cfrg-bls-signature-05, the de-facto Ethereum / Filecoin / Tendermint suite). Two flavours relevant here:

• Plain aggregation. N signatures over (potentially different) messages can be combined into a single 96-byte aggregate; verification is one pairing per distinct message + one pairing for the aggregate. (Or, with a proof-of-possession scheme to defeat rogue-key attacks, one pairing for the aggregated public key when all signers signed the same message.)
• Threshold BLS. With a distributed-key-generation (DKG) ceremony, t-of-n signers can produce a single 96-byte signature verifiable under one 48-byte aggregate public key. The signature is indistinguishable from a non-threshold one — no list, no membership leak.

Native curve: BLS12-381. Hash-to-curve per RFC 9380. Domain-separation strings are part of the standard.

1.3 Schnorr / MuSig2 over Ed25519 or secp256k1

MuSig2 (Nick et al. 2020, IETF draft draft-bip-musig2, Bitcoin BIP 327). N parties produce a single Schnorr signature verifiable under a single aggregated public key. Two-round protocol: nonce commitment + partial signature exchange. Strictly n-of-n in its simple form; threshold variants (FROST, Komlo–Goldberg 2020) need a DKG.

Sister scheme FROST (Flexible Round-Optimized Schnorr Threshold) handles t-of-n natively in two rounds with a one-time DKG, and is the Schnorr-side answer to threshold BLS without pairings. IETF: draft-irtf-cfrg-frost.

The signature is 64 bytes (Ed25519-compatible if instantiated over edwards25519) or 64 bytes (Schnorr over secp256k1). The aggregated public key is 32 bytes.

1.4 "Off-chain orchestration" / signed-list compaction

A non-cryptographic option: members sign individually, an orchestrator collates the list, and a single Ed25519 signature over the list of (member, signature) pairs is published as the canonical artefact. This is what Tendermint's pre-aggregation block-vote handling does in some ABCI configurations and what most multisig wallets do in practice. It does not reduce signature size under verification; it reduces transmission and amortises lookup. We include it because for HERALD's typical N (≤ 16 Heralds, ≤ small-number quorum) the cryptographic gain of aggregation may not justify the protocol cost.

2. The comparison matrix

The table below is for the 7-of-10 case (a plausible upper bound for both threshold-Herald lineage and small collective quorums; chosen because it is small enough to be realistic and large enough to expose aggregation's wins).

Sources: BLS sizes and pairing counts are from blst's benchmarks and the IRTF BLS draft; MuSig2 / FROST claims are from BIP 327 and the FROST CFRG draft; Ed25519 timings are from ed25519-dalek and @noble/ed25519 published benchmarks; library survey is by inspection of the package ecosystems as of 2026-05.

3. Reading the matrix against HERALD's specific needs

3.1 Threshold Herald lineage attestation [EXT §3.3]

Operating regime:

• N is small (Heralds are operators — realistically ≤ 16 globally, threshold typically 3–5).
• Member identity must be visible. The diversity_policy requires that verifiers check each Herald against jurisdiction / ownership / key-management dimensions ([EXT §3.3], line 245). A scheme that hides the member set (threshold BLS, FROST) defeats this requirement — verifiers cannot check diversity if they cannot see who signed.
• Signatures are produced asynchronously across operators in different jurisdictions. Interactivity is hostile — a 2-round protocol means coordinated nonce ceremonies between (e.g.) a US Herald and a German Herald per attestation. That is prohibitive for a primitive intended to be run across thousands of attestations per day.
• Per-Herald revocation must remain trivial ([EXT §3.6], "A Herald MUST be able to revoke its own prior attestations"). A scheme that requires DKG-rerun on membership change is incompatible with EXT §3.6.

Conclusion for §3.3. Sequential Ed25519 is not just acceptable — it is the only scheme that satisfies the diversity-policy verification requirement. Aggregation actively breaks the primitive.

3.2 Collective / quorum attestation [EXT §7.4]

Operating regime:

• N is potentially larger (a "collective" can be 100s; threshold may be in the dozens).
• Member identity must still be visible — [EXT §7.4] line 553 requires that verifiers reject quorums whose members do not satisfy the collective's diversity_policy. Same constraint as §3.1.
• Members are software agents (sigils), not human-operated Heralds — interactivity is cheaper, but still requires online liveness during signing windows. [THREATS] §6.4 (signed envelope-traffic) raises concerns about offline / asynchronous signers; FROST/MuSig2 require all chosen signers online during the signing rounds.
• Per-member dropout matters. A collective member may molt ([EXT §1]) or be deprecated ([EXT §9.1]) at any time. Sequential Ed25519 lets the verifier evaluate "≥ threshold valid signatures from current members" by re-checking the list against the current membership. Threshold BLS / FROST give one signature whose validity is tied to a frozen group key — a member rotation invalidates the entire group key without DKG-rerun.
• The cap-on-N is wrong. If a collective has 1000 members and threshold 100, sequential Ed25519 lists 100 × 64-byte sigs = 6.4 KB. That is substantial but not absurd; an aggregated single signature would be 96 B (BLS) or 64 B (Schnorr). At extreme N the aggregation case strengthens.

Conclusion for §7.4. Sequential Ed25519 remains the default, but a signature-suite-registered aggregation path is justified for large collectives where:

• N is large enough that the list dominates envelope size; AND
• The collective's diversity_policy is structurally pre-verifiable — i.e. the membership composition is itself attested in a separately-verifiable artefact (collective birth attestation + quorum_membership attestations [EXT §7.4 lines 555–556]) — so that the on-the-wire signature does not need to carry the per-member identities for diversity checking.

This second condition is the load-bearing one and is currently not addressed by EXT. A well-designed aggregation scheme for collectives requires a companion "membership root" primitive.

3.3 Origin signature

The origin signature ([SPEC §3.4] line 185, [EXT §6.1] line 418) is and remains a single signer, single algorithm. No aggregation rationale applies. It stays Ed25519 over herald.sig.origin.v1.

4. Post-quantum status — and why it dominates the registry decision

All three candidate schemes (sequential Ed25519, BLS, Schnorr / MuSig2 / FROST) are broken by Shor's algorithm against a CRQC. The aggregation question is therefore independent of the post-quantum question: whatever HERALD chooses for v0.2 will need to be migrated when (not if) PQ migration begins. The relevant registered post-quantum candidates as of 2026-05 are:

• ML-DSA (Dilithium, NIST FIPS 204, August 2024). Lattice. ~2.4 KB signatures (level 2), ~2.5 KB public keys. No native aggregation scheme. Concatenation is the only aggregation today.
• SLH-DSA (SPHINCS+, NIST FIPS 205, August 2024). Hash-based. 8–17 KB signatures. No aggregation.
• Falcon (NIST FIPS 206, expected 2026). Lattice. ~666 B signatures. No standard aggregation.

Aggregation in the PQ world is a research topic (lattice-based aggregate signatures: Boneh–Kim 2020; Aggregate Falcon: in flux). There is no production-ready PQ aggregation scheme as of 2026-05.

Implication. Choosing BLS or FROST today buys aggregation properties that will not survive PQ migration. The migration target (probably ML-DSA or some post-NIST hybrid) is not aggregable. So an aggregation primitive in HERALD is a 5–10 year asset, after which it is replaced by a PQ scheme that returns to concatenated lists.

This is a strong argument for delaying registry-admission of BLS / FROST until either:

(a) HERALD has a concrete deployment for which the size or verification-cost win is load-bearing, OR
(b) A PQ aggregate scheme is standardised, in which case the v0.2 aggregation choice is leapfrogged anyway.

5. Other constraints from the SPEC / EXT cryptographic profile

5.1 Domain separation

[SPEC §3.6] lines 208 and [EXT §6.3] lines 432–442 mandate dom_sep || canonical_body signing. Ed25519 supports this trivially (just concatenate). BLS supports it via the IRTF spec's dst parameter. MuSig2 / FROST IETF drafts include explicit dst slots.

No scheme is excluded on domain-separation grounds. But the registry entry for any new suite must specify the role-binding rule — what scope values that suite is permitted for. The current rule in [EXT §6.6] line 460 is "alg" matched against the registry; aggregation suites are likely restricted to quorum and possibly herald_endorsement scopes only, never origin.

5.2 Progressive-signing semantics

[EXT §6.4] lines 444–448: each signature is computed over the envelope with signatures replaced by all prior signatures in declaration order. This is intrinsically a list model. Aggregation breaks it.

For aggregated signatures to fit into the multi-signature envelope, the spec needs an exception clause: an aggregated signature represents a bundle that occupies one slot and signs over the same canonical input as a single co-signature would. This is implementable but is not a registry-only change — it requires an EXT amendment to §6.4 specifying how the aggregated entry is positioned in the array and what canonical input it covers.

5.3 The "no-duplicate-signer" rule

[SPEC §3.4] line 188: "The same signer MUST NOT appear twice in signatures[]." For aggregation schemes that hide member identity (threshold BLS, FROST), there is no per-signer entry — the rule degenerates. For schemes that expose member identity (BLS plain, MuSig2 with explicit member list), the rule continues to apply.

5.4 Verifiability across language ecosystems

HERALD's reference libraries target TS, Python, Go, Rust ([SPEC §11], envelope reference). The current registered suite (Ed25519) is universally available with audited, RFC-8032-conformant implementations in all four.

For the candidate aggregation suites:

• BLS12-381. Production-grade in Rust (blst), Go (herumi/bls), Python (blspy, py_ecc), TypeScript (@noble/bls12-381, @chainsafe/bls). All four ecosystems have audited libraries. This is the strongest candidate from a portability standpoint — the Ethereum and Filecoin ecosystems have done the work.
• MuSig2 / Schnorr. Production in Rust (BIP 327 implementations, secp256k1-zkp), Python (secp256k1-py), TS (@cmdcode/musig2). Go support is weakest — most implementations are tied to Bitcoin tooling. Audit posture is mixed; MuSig2 only stabilised in BIP 327 in late 2023.
• FROST. Reference implementation by Zcash Foundation (frost-ed25519, frost-secp256k1, frost-ristretto255) in Rust, audited 2023. Python and Go ports exist but are community-maintained; TS support is early. Less universally available than BLS.

For HERALD-style cross-language interop testing (T-001 vectors, T-017 conformance), BLS has the cleanest story; FROST is feasible but concentrates trust in fewer audited implementations.

6. Threats and footguns

6.1 Rogue-key attacks (BLS plain)

If members publish their BLS pubkeys without proof-of-possession, an attacker can craft a key pk_bad = pk_target⁻¹ ⊕ pk_chosen and sign a malicious message valid under the aggregate. The defence is requiring proof-of-possession (herald.sig.bls_pop.v1 domain tag) at registration. This adds a key-registration ceremony to HERALD's birth-attestation flow that does not exist today. Material cost.

6.2 Nonce reuse (MuSig2 / FROST)

MuSig2 requires fresh nonces per signing session; reuse across sessions leaks the secret key. Implementations have been published with this bug (e.g. ROAST 2022 paper documenting two production wallet flaws). Sequential Ed25519 is RFC 8032 deterministic and immune. For autonomous agents that may crash, restore from backup, and re-sign — a real risk.

6.3 DKG ceremony attack surface

Threshold BLS and FROST both require an initial distributed-key-generation ceremony. A malicious participant can refuse to publish their share, biasing the resulting key, or learn unexpected information from honest participants. Production DKGs (Pedersen, Gennaro–Jarecki–Krawczyk–Rabin) are well-studied but operationally heavy; running one across an ad-hoc collective of agents is a protocol not a library call.

6.4 Trusted setup (BLS only)

BLS12-381 itself does not need a trusted setup. But pairing-friendly curve constructions in general are scrutiny-prone: curve choice, generator subgroup membership, twist-attack resistance all matter. blst handles these correctly; ad-hoc implementations often do not. Conclusion: only blst (Rust) and herumi/bls (Go) and @chainsafe/bls (TS) are reviewable; everything else carries implementation risk.

6.5 Membership-transparency loss

This is the load-bearing concern for HERALD. Both [EXT §3.3] and [EXT §7.4] require the verifier to evaluate each member against a diversity_policy. A scheme that hides members defeats the policy check. Threshold BLS and FROST are therefore inadmissible for these primitives without a separately-attested membership-witness primitive that does not currently exist in EXT.

This is the single biggest reason the recommendation below is not "adopt BLS now."

7. Recommendation

7.1 v0.2 (current registry)

Keep sequential Ed25519 as the only registered suite for quorum-bearing envelopes. [EXT §6.6] already names this. No change to the registry.

Rationale, ordered by weight:

1. Diversity-policy verification ([EXT §3.3] line 245, [EXT §7.4] line 553) requires per-member visibility. Aggregation schemes that hide members violate the requirement; aggregation schemes that don't hide members give modest wins at the cost of complexity.
2. Per-member revocability ([EXT §3.6], [EXT §1] molt) requires that membership changes don't invalidate aggregated artefacts. Threshold schemes fail this; non-threshold aggregation passes only awkwardly.
3. PQ migration is the load-bearing future, and no PQ aggregation is production-ready. Investing in a non-PQ aggregation primitive now creates churn at PQ migration time.
4. Library audit posture. Ed25519 is the most-audited, most-portable primitive in the cryptographic landscape. Adding BLS / FROST narrows the audit pool.
5. The size win is small at HERALD's expected N. For 7 Heralds, the wire savings are ~350 B per attestation; for 10-of-100 collectives, ~6 KB. Neither is a system bottleneck.

7.2 Conditional admission path

Two specific conditions, either of which justifies admitting a new suite:

Path A (BLS for large collectives). Admit BLS12-381 (with proof-of-possession) into the suite registry only for scope: "quorum" envelopes from collectives whose membership is independently attested. This requires three companion changes outside R-210's scope:

• A membership_witness primitive — a Merkle root of (member_sigil, member_pubkey) pairs published at the collective's birth, refreshed on member rotations.
• Verifiers MUST resolve the membership root and compute diversity-policy compliance against the attested members at the signature's ts, independently of the on-wire signature.
• An EXT §6.4 amendment specifying that an aggregated signature occupies a single slot in signatures[] with a designated aggregator field.

Path B (PQ-ready post-2027). When ML-DSA aggregation (or a successor) reaches IRTF / IETF standardisation, register that scheme directly and skip the BLS detour. This is the recommended path unless a deployment between now and PQ standardisation has a load-bearing aggregation requirement (which v0.2 does not).

7.3 What NOT to do

• Do not admit threshold BLS or FROST in any form before the membership-witness primitive exists. The diversity-policy guarantee is the central anti-Sybil claim of [EXT §3.3] and [EXT §7.4]; obscuring members removes it.
• Do not mix aggregation suites with the origin signature. The origin signature stays Ed25519 forever (or migrates to ML-DSA wholesale at PQ migration). Aggregation lives only in co-signature slots.
• Do not deploy MuSig2-style 2-round protocols across Heralds for [EXT §3.3]. The asynchronous, cross-jurisdiction signing pattern is what threshold-Herald attestations exist for; making them require synchronous nonce ceremonies defeats the diversity goal.

8. What this report deliberately does not answer

• Concrete Merkle root format for the proposed membership_witness primitive. That is a follow-on EXT amendment, not within R-210.
• Reputation-weighting of aggregated signatures. Whether an aggregated 7-of-10 signature is "stronger" than 7 sequential signatures for app-layer reputation is a policy question for [CHARTER §reputation]; the protocol layer treats them as equivalent.
• Specific PQ scheme to migrate to. The NIST competition's final selections post-FIPS 204/205/206 are still being analysed. R-210 punts to a future R-220 or similar.
• Hybrid (classical + PQ) aggregation. Possible in theory (Bindel et al. 2017); no standardisation yet.
• Proof-of-possession ceremony design for BLS adoption. Mentioned as a precondition in §7.2 but not specified.

9. Follow-on tasks

These belong as new entries in TODO.md; this report does not edit TODO.md (per the worker contract).

• R-220 (proposed): PQ signature suite review for HERALD — ML-DSA / SLH-DSA / Falcon migration sketch, including hybrid construction options.
• EXT amendment proposal: membership_witness primitive and the aggregator slot in signatures[]. (Out of scope for R-210; this report identifies the gap.)
• R-221 (proposed): Empirical envelope-size analysis at expected HERALD deployment scale, to validate the "the size win is small at expected N" claim in §7.1.
• D-318 (proposed): Audit-posture survey of blst, frost-ed25519, and @noble/bls12-381 for HERALD's interop requirements.

10. Citations

HERALD documents (read 2026-05-05)

• SPEC.md §3.4 — Multi-signature envelopes (full semantics), lines 181–191
• SPEC.md §3.6 — Domain separation, lines 206–222
• EXT.md §3.3 — Threshold attestations, lines 230–247
• EXT.md §6 — Multi-signature semantics, lines 410–462
• EXT.md §6.3 — Domain separation, lines 432–442
• EXT.md §6.4 — Progressive signing, lines 444–448
• EXT.md §6.6 — Signature-suite registry and downgrade protection, lines 458–462
• EXT.md §7.4 — quorum, lines 538–559 (the explicit "EXT does not specify how members coordinate" lacuna)
• THREATS.md line 374 — "Quorum semantics ... must be specified before quorum is enabled"
• THREATS.md lines 85, 152, 322, 412 — Herald-cartel and threshold-attestation rationale

External / standards

• IRTF CFRG draft-irtf-cfrg-bls-signature-05 — BLS Signatures
• IRTF CFRG draft-irtf-cfrg-frost — Flexible Round-Optimized Schnorr Threshold
• BIP 327 — MuSig2 for BIP-340-compatible Multi-Signatures (Bitcoin)
• RFC 8032 — Edwards-Curve Digital Signature Algorithm (EdDSA / Ed25519)
• RFC 9380 — Hashing to Elliptic Curves
• NIST FIPS 204 (ML-DSA / Dilithium, August 2024)
• NIST FIPS 205 (SLH-DSA / SPHINCS+, August 2024)
• Boneh, Lynn, Shacham (2001) — Short signatures from the Weil pairing
• Nick, Ruffing, Seurin (2020) — MuSig2: Simple Two-Round Schnorr Multi-Signatures
• Komlo, Goldberg (2020) — FROST: Flexible Round-Optimized Schnorr Threshold Signatures
• ROAST (Ruffing, Ronge, Jin, Schneider-Bensch, Schroeder, USENIX 2022) — extending two-round Schnorr threshold signatures, with discussion of nonce-reuse failures in production wallets

Library survey (verified by package-registry inspection 2026-05-05)

• Rust: ed25519-dalek 2.x, blst 0.3.x, frost-ed25519 1.x (Zcash Foundation), secp256k1-zkp, musig2
• Go: crypto/ed25519 (stdlib), github.com/herumi/bls-eth-go-binary, go.dedis.ch/kyber/v4
• Python: cryptography, PyNaCl, blspy (Chia), py_ecc (Ethereum Foundation), pyfrost
• TypeScript: @noble/ed25519, @noble/bls12-381, @chainsafe/bls, @frostlab/frost-ed25519, @cmdcode/musig2

External references are by name + draft / RFC / FIPS number rather than URL — URLs change; identifiers don't.