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).
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.
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.
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.
| 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. |
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.
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:
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.
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.
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 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).
This EIP deliberately does not specify, and defers entirely to leanSpec and the cited research:
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) likewise assigns heavier custody work to better-resourced participants while keeping the network's checks light.
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.
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). 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.
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.
These aspects of the role are not yet settled, and are noted here rather than resolved:
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.
Consensus test vectors for post-quantum attestation aggregation validity, aggregate rejection, gossip handling, and fork activation are present in the PQ consensus specification.
A reference implementation is expected to live with the PQ consensus implementation and interop devnets before this EIP advances beyond Draft.
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.
Copyright and related rights waived via CC0.