---
eip: 8292
title: Post-Quantum Attestation Aggregators
description: Describes the aggregator role that aggregates validator attestations into one succinct proof in PQ consensus
author: Anshal Shukla (@anshalshukla), Gajinder Singh (@g11tech), Parthasarathy Ramanujam (@ch4r10t33r), Guillaume Ballet (@gballet), Shariq Naiyer (@shariqnaiyer), Kolby Moroz Liebl (@KolbyML), Unnawut Leepaisalsuwanna (@unnawut), Tom Wambsgans (@tomWambsgans), Thomas Coratger (@tcoratger), Justin Drake (@JustinDrake)
discussions-to: https://ethereum-magicians.org/t/eip-8292-pq-attestation-aggregators/28778
status: Draft
type: Standards Track
category: Core
created: 2026-06-07
---

## Abstract

Post-Quantum (PQ) Ethereum replaces the beacon chain's BLS signatures with post-quantum, hash-based signatures, which are individually larger than BLS signatures and, unlike BLS, cannot be cheaply combined by adding the signatures themselves. PQ consensus therefore performs attestation aggregation by generating a succinct cryptographic proof that the post-quantum signatures attached to many validator attestations are valid, using a specialized minimal virtual machine. Producing such proofs is far more computationally expensive than the elliptic-curve addition used to aggregate BLS signatures, so post-quantum consensus separates aggregation from block production and assigns it to an opt-in, higher-specification participant: the *aggregator*. Any node may opt in as an aggregator if it has the hardware to support proving on the slot's critical path. This EIP specifies the aggregator role. The authoritative definitions of the signature scheme, proof system, wire formats, and consensus rules live in the PQ consensus specification (leanSpec).

## Motivation

### Hash-based signatures do not aggregate like BLS

Ethereum's beacon chain authenticates validator votes with BLS signatures over the BLS12-381 curve. A BLS signature is 96 bytes and a public key is 48 bytes, and crucially an *aggregate* of many BLS signatures over a common message is still only 96 bytes, because aggregation is the addition of curve points and an entire set can be checked with a single pairing equation. This property is what lets a beacon block carry the votes of a whole committee in constant space.

Hash-based signatures have no such structure. Their security rests only on hash functions — but there is no cheap way to combine many signatures into one short object. The PQ consensus signature scheme (a stateful variant of XMSS, the eXtended Merkle Signature Scheme) produces signatures considerably larger than BLS and offers no native aggregation. The exact size depends on the chosen parameter set: the instance currently used by the leanVM aggregation engine is about 1.17 KiB. These signatures are more than an order of magnitude larger than a 96-byte BLS signature, and N signatures cost roughly N times as much.

### Aggregation moves into a proof, and proving needs its own role

Because the signatures cannot be combined directly, PQ consensus aggregates attestations by proving their signatures: a post-quantum succinct argument proves that the signatures attached to some number of attestations are all valid. The proof is generated by leanVM, a minimal virtual machine purpose-built for proofs aggregation. Measured aggregate proof sizes are on the order of 127–344 KiB depending on configuration, and the networking target is to propagate a roughly 256 KiB proof in under one second, broadly constant regardless of how many attestations were aggregated.

Generating these proofs is expensive, heavier than the curve addition a BLS aggregator performs, and heavier than a typical home-staking machine should be expected to do on the slot's critical path. If every validator (or every committee aggregator) had to prove, the network would either centralize proving onto whoever has the hardware or miss slots. PQ consensus therefore decouples aggregation from block production and gives it to an opt-in, higher-specification participant — the aggregator — while keeping signature *verification* cheap so that proposers and ordinary validators stay light.

## Specification

This EIP introduces aggregators as beacon-chain consensus participants; the hard fork that activates them is assigned by the relevant meta EIP. The execution layer is unchanged by this EIP. The authoritative definitions — the signature scheme and its parameters, the proof system, the SSZ containers and wire formats, the gossip topics, the aggregation algorithm, and the consensus and fork-choice rules are given by the PQ consensus specification (leanSpec). This section specifies the aggregator-role behavior inline; everything else is deferred to leanSpec.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 and RFC 8174.

### Constants

| Name | Value | Description |
| - | - | - |
| `SUBNET_COMMITTEES` | TBD | The number of gossip subnets the validator set is partitioned across. The value is not yet finalized (also undecided in leanSpec). |
| `MAX_ATTESTATIONS_DATA` | `8` | The maximum number of distinct attestation messages a proposer includes in one block. |

### The aggregator role

Validators are partitioned across `SUBNET_COMMITTEES` gossip subnets. Each validator signs its vote and gossips the signed attestation on its assigned subnet.

A node MAY opt in as an aggregator, for example by setting an `is_aggregator` flag in its configuration. Aggregation is not a separately selected validator duty, and opting in MUST NOT be gated on a protocol-defined stake threshold; any node MAY opt in provided it can meet the timing budget below.

An aggregator MUST subscribe to at least one subnet. For each distinct attestation message on the subnets it serves, it MUST collect the signed attestations, prove the attached signatures into a single aggregate for that message, and gossip that aggregate on the aggregation topic. An aggregator SHOULD complete collection and proving within the slot's aggregation interval defined by leanSpec; an aggregate produced too late for the proposer to include provides no value.

A node whose validators hold at least `SUBNET_COMMITTEES * 32 ETH` of combined stake SHOULD act as a *super-aggregator*: it SHOULD subscribe to and aggregate across all subnets. This mirrors the PeerDAS super-node, which is likewise expected to cover the whole partition rather than a single slice.

Beyond producing and gossiping aggregates, this role introduces no new consensus or fork-choice rule; block production, attestation inclusion, and fork choice remain as defined by leanSpec.

### Levels of aggregation

Aggregation proceeds in stages with distinct timing characteristics. Two of these stages are the aggregator's work; the final, block-level step belongs to the proposer and is described here only to delimit the role:

- *Leaf (signature) aggregation.* The first level: for a given attestation message, an aggregator proves the raw signatures attached to the collected attestations into a single aggregate. Many individual hash-based signatures over a common message become one succinct proof.
- *Recursive (proof) aggregation.* Aggregators may then recursively combine several partial aggregates for the same message into a single aggregate-of-aggregates, again via leanVM.
- *Block-level proof aggregation — performed by the proposer, not by aggregators.* The block proposer takes the per-message aggregates and folds them into a single block proof that covers multiple distinct attestation messages at once, bounded by `MAX_ATTESTATIONS_DATA` distinct attestation messages per block. This is explicitly a proposer duty and is **not** part of the aggregator role; it is mentioned here only to make the boundary clear — aggregators produce per-message aggregates, whereas combining many messages into one block proof is the proposer's job.

These stages do not share a cost profile. Leaf aggregation over a flat batch is comparatively cheap, whereas recursive aggregation grows with the number and depth of the partial aggregates it folds together; the two therefore have different slot budgets. The exact aggregation algorithm, the recursion strategy, the per-block message cap, and the intra-slot timing are defined by leanSpec; this EIP only fixes that the aggregator role spans the leaf and recursive levels.

### Aggregation targets

The following are non-normative soft targets, not consensus requirements; the authoritative bounds and parameters live in leanSpec. Proof size is governed by leanVM's inverse-rate parameter (`LOG_INVERSE_RATE`); the measured figures below are taken at its production setting, from the leanSig/leanVM benchmark suite.

| Target | Value | Notes |
| - | - | - |
| Aggregate proof size (hard bound) | ≤ 512 KiB | leanSpec container limit |
| Typical proof size | ~185–230 KiB | Near-constant in the number of votes covered |
| Propagation | ~256 KiB in under 1 s | Broadly constant in vote count |
| Distinct messages per block | `MAX_ATTESTATIONS_DATA` (8) | Proposer-side inclusion bound |

Measured proof size grows only slightly with batch size and stays well under the 512 KiB bound (single-message aggregate, production inverse rate):

| Signatures aggregated | Proof size |
| - | - |
| 125 | ~185 KiB |
| 250 | ~194 KiB |
| 500 | ~206 KiB |
| 1000 | ~227 KiB |

Proving latency, by contrast, is hardware-bound, and it — not proof size — sets the role's floor, since aggregation must finish within the slot's dedicated aggregation interval. Time to prove a single-message aggregate over 1000 signatures:

| Machine (physical cores / RAM) | Proving time |
| - | - |
| 2 cores / 15 GiB | ~11.0 s |
| 8 cores / 59 GiB | ~3.7 s |
| 16 cores / 118 GiB | ~2.6 s |

Holding proof size and proving time to soft targets, rather than letting them drift, is what keeps aggregator hardware requirements from ratcheting up silently.

### Resource dimensions

An aggregator must be provisioned along several dimensions. No fixed minimum is mandated by leanSpec; the envelopes below are measured from the leanSig/leanVM benchmark suite and illustrate the shape of the requirement, with [EIP-7870](./eip-7870.md) as the current full-node baseline.

| Dimension | Measured envelope | Notes |
| - | - | - |
| CPU / parallelism | ~2.6 s (16 cores) to ~11 s (2 cores) for a 1000-signature batch | Multi-core-bound; core count, more than clock speed, governs whether an aggregator meets its slot budget. |
| Memory | ~1.5 GiB (small batch) to ~6.6 GiB (largest workloads) | Scales with batch size and recursion depth. |
| Bandwidth | Propagate ~256 KiB aggregates each slot | Plus ingest of many individual attestations from subscribed subnets. |
| Storage | Buffer collected attestations for the slot's aggregation window | — |

Whether these envelopes harden into a published minimum specification — and the prover centralization that a higher hardware bar would imply — remains open (see Open questions and Security Considerations).

### Out of scope

This EIP deliberately does not specify, and defers entirely to leanSpec and the cited research:

- the leanSig / XMSS signature scheme, its parameters, and exact signature and key sizes;
- the leanVM instruction set and the proof system (WHIR[^whir], SuperSpartan, Logup, and their soundness assumptions);
- the SSZ byte layout of attestations, signatures, aggregates, and proofs, and the gossip message schema;
- the mechanics of migrating validator keys from BLS to the hash-based scheme;
- the consensus and fork-choice rules of PQ consensus.

## Rationale

### Why a separate role rather than a duty for every validator

BLS aggregation is cheap enough that the beacon chain can select ordinary validators as committee aggregators each slot. Proving the validity of hash-based signatures is not cheap, so the same approach would push heavy proving onto home-staking hardware on the critical path. Separating proving into an opt-in, higher-specification role keeps the expensive work where the hardware is, while signature *verification* stays inexpensive for everyone else — preserving the ability of ordinary validators and proposers to participate on modest machines. This mirrors the asymmetry that motivates other recent designs: PeerDAS ([EIP-7594](./eip-7594.md)) likewise assigns heavier custody work to better-resourced participants while keeping the network's checks light.

### Why the role is opt-in

Any node may opt in as an aggregator if it can support the required bandwidth, storage, and proving load. This keeps the role permissionless while making the hardware requirement explicit: the protocol relies on enough capable nodes choosing to aggregate, rather than on every validator being able to prove.

The term "super-aggregator" is borrowed by "super-node" analogy from PeerDAS, where validators with stake at least `128 * 32 ETH` are expected to hold all columns for stability.

### Not the same as today's committee aggregator

The beacon chain already has a committee aggregation duty in which a randomly selected committee member combines its committee's BLS signatures (see the committee-index changes in [EIP-7549](./eip-7549.md)). That duty performs a cheap point addition and is selected secretly via a signature-based selection proof. The PQ attestation aggregator is a different thing: it generates a succinct *proof* over signatures that cannot be combined directly, it is compute-heavy, and in the current devnets it is a statically configured opt-in role rather than a secretly drawn duty.

### Centralization trade-offs and mitigations

Concentrating proving in a smaller set of well-resourced aggregators is the main decentralization risk this role introduces. The mitigations available are: running several aggregators so that none is a single point of failure; keeping verification cheap so the validating set stays broad even if the proving set does not; and holding proof size and proving time to soft targets so that hardware requirements do not ratchet up silently.

### Open questions

These aspects of the role are not yet settled, and are noted here rather than resolved:

- *Incentives.* As with today's committee aggregators, there are currently no explicit protocol rewards or penalties for aggregators. Because post-quantum proving is costly, relying solely on implicit incentives is riskier, and whether to add explicit rewards is unresolved.
- *Hardware and prover centralization.* No fixed minimum hardware specification has yet been mandated, though measured envelopes exist (see Resource dimensions in the Specification) and aggregators are currently expected to meet at least the [EIP-7870](./eip-7870.md) full-node baseline. Whether those envelopes harden into a published minimum — and the centralization that a higher hardware bar would imply — is the principal open risk.

## Backwards Compatibility

This EIP is part of the broader migration from BLS signatures to post-quantum, hash-based signatures, and takes effect at whichever beacon-chain hard fork the relevant meta EIP assigns. Signatures and aggregates from before and after that transition do not interoperate, so clients from before the fork cannot validate post-fork aggregate proofs without implementing the post-quantum consensus changes.

## Test Cases

Consensus test vectors for post-quantum attestation aggregation validity, aggregate rejection, gossip handling, and fork activation are present in the PQ consensus specification.

## Reference Implementation

A reference implementation is expected to live with the PQ consensus implementation and interop devnets before this EIP advances beyond Draft.

## Security Considerations

Introducing a dedicated, higher-specification aggregator concentrates a critical step of consensus in a smaller set of participants. The considerations below cover the resulting risks — liveness and censorship, the soundness of the proof that aggregation now depends on, the centralization pressure from proving hardware, and the knock-on effect on solo stakers — together with the mitigations this design relies on.

- *Liveness and censorship.* Aggregators sit on the path between signing and finality: if the available aggregators stall or selectively omit votes, proposers cannot include sufficient coverage and finality degrades. The current requirement that at least one aggregator be present makes this concrete. Running redundant aggregators is the primary mitigation.
- *Proof soundness.* The security of aggregation reduces to the soundness of the leanVM proof system: a false proof would let an attacker fabricate consensus participation. The current leanVM instantiation is reported to provide roughly 124-bit classical and 62-bit quantum security, short of the NIST Level 1 target (128-bit classical, 64-bit quantum); closing that gap (for example with larger digests) is acknowledged ongoing work, and this role description inherits whatever assurance leanSpec ultimately fixes.
- *Prover centralization.* The hardware needed to prove competitively is the chief centralization concern. It matters for security insofar as a captured or colluding set of aggregators must not be able to compromise *verification*, which remains cheap and broadly performed, nor to censor by being the sole available producers; running several aggregators and keeping the role open to any capable node are the available mitigations.
- *Effect on solo stakers.* The role is designed so that ordinary validators and solo stakers continue to *verify* cheaply — checking one succinct proof rather than thousands of individual attestation signatures — and do not need aggregator-grade hardware to keep validating or proposing. The caveat is that they depend on the aggregator set for liveness.

## Copyright

Copyright and related rights waived via [CC0](../LICENSE.md).

[^whir]:

    ```csl-json
    {
        "id": "https://doi.org/10.1007/978-3-031-91134-7_8",
        "type": "paper-conference",
        "title": "WHIR: Reed–Solomon Proximity Testing with Super-Fast Verification",
        "author": [
            { "given": "Gal",        "family": "Arnon"  },
            { "given": "Alessandro", "family": "Chiesa" },
            { "given": "Giacomo",    "family": "Fenzi"  },
            { "given": "Eylon",      "family": "Yogev"  }
        ],
        "issued": { "date-parts": [[2025]] },
        "container-title": "Advances in Cryptology – EUROCRYPT 2025",
        "DOI": "10.1007/978-3-031-91134-7_8",
        "URL": "https://doi.org/10.1007/978-3-031-91134-7_8",
        "custom": {
            "additional-urls": [ "https://eprint.iacr.org/2024/1586" ]
        }
    }
    ```