The Aggregation Problem Nobody Draws a Diagram For
You're a node operator. Slot boundary hits, your client fires an attestation, and somewhere upstream sixteen pseudorandomly selected strangers are supposed to collect yours, merge it with hundreds of others, and hand a single tidy aggregate to the block proposer before the window closes. Every twelve seconds. Without fail. Now multiply the number of people doing that by four, and ask yourself whether "BLS signatures scale" is actually a complete sentence.
It isn't. The short answer to the question you searched: a larger validator set does not linearly increase the cost of attestation aggregation under BLS, because BLS signatures can be combined. But "can be combined" hides a lot of engineering pain. Aggregation efficiency depends on committee structure, subnet architecture, and how many aggregators are selected per slot. Get those wrong, or let the validator set balloon without adjusting the parameters, and you end up with bloated attestation payloads, slower propagation, and a consensus layer that's quietly choking.
What BLS Aggregation Actually Does
BLS stands for Boneh-Lynn-Shacham, a signature scheme with one property that makes it almost purpose-built for blockchain consensus: you can combine N signatures over the same message into a single signature, and verify that combined signature with a single pairing operation rather than N separate ones.
The pairing operation is the expensive part. On current hardware, one BLS pairing costs roughly 1-2 milliseconds. Verifying 500,000 individual ECDSA signatures (the kind Bitcoin uses) would take hours. Verifying one aggregated BLS signature over 500,000 attestations to the same checkpoint takes milliseconds. That's the entire reason Ethereum's proof-of-stake is feasible at its current validator count.
But aggregation isn't free. Someone has to do the aggregating. Signatures only collapse cleanly when they're over identical messages. And the network has to route individual signatures to aggregators before the slot closes. Each of those steps carries a cost that scales with validator set size in ways that aren't immediately obvious.
How Committees and Subnets Slice the Problem
Ethereum doesn't ask all active validators to broadcast their attestations to all other validators. That would be catastrophic: 500,000 validators each gossiping a 96-byte signature produces roughly 48 MB of raw signature data per slot, before any overhead. At 12-second slots, the network would need to move nearly 4 MB/s of attestation data alone, across every node.
Unworkable.
The consensus spec divides the active validator set into committees, one per slot across a 32-slot epoch. Each committee is assigned to an attestation subnet. Within that subnet, a small number of validators (currently 16 per subnet, selected pseudorandomly) act as aggregators. They collect individual attestations from subnet peers, combine them into a single aggregate signature, and broadcast that aggregate to the broader network.
The beacon chain then includes only the aggregates, not the individual signatures. A block with 128 committee slots carries 128 aggregate attestations, not 500,000 individual ones. The actual payload is manageable.
This architecture is what makes the system work. It's also what starts bending under pressure when the validator set grows.
Where the Strain Shows Up
Consider two validators: call them Priya and Marcus. Both run identical hardware, identical client software, both assigned to committees in the same epoch. Priya's epoch has roughly 400,000 active validators. Marcus's has grown to 900,000.
Priya's committee represents about 0.13% of the active set. Marcus's represents about 0.057%. Same absolute committee size, very different share of the validator population.
For the aggregation layer, this matters in two ways. First, the number of committees per epoch is fixed at 64. As the validator set grows, each committee gets larger, which means more individual attestations flowing into each aggregator, more bandwidth consumed on each subnet, and more processing time to produce the final aggregate. The aggregator's job is proportionally harder.
Second, the bitfield that encodes which validators signed grows linearly with committee size. A 512-member committee needs a 64-byte bitfield. A 2,000-member committee needs a 250-byte bitfield. Multiply that across 64 committees per epoch and you see why attestation inclusion data in blocks grows steadily as the validator set expands. Not because signatures got bigger. Because the participation bitfields did. Ethereum researchers have tracked this rising across successive periods of validator growth, and it's about as subtle as a slowly blocked drain.
The deeper issue is aggregator selection. Sixteen aggregators per subnet sounds like plenty, but if the network is under load, or if those sixteen happen to be geographically clustered (which pseudorandom selection can't fully prevent), you get incomplete aggregation: some individual attestations miss the window and arrive too late to be included. The block proposer sees a fragmented picture. Attestation inclusion rate drops. Validators miss rewards.
Ask yourself: have you ever watched your validator's attestation effectiveness slip during a period of high network activity and assumed it was your setup? It probably wasn't.
The Honest Tension: Safety vs. Efficiency
More validators means better economic security. To corrupt a finalized checkpoint under Casper FFG, an attacker needs to control more than one-third of the active stake. A larger validator set, assuming genuine decentralization, raises the absolute cost of that attack. Nobody serious disputes this.
BLS aggregation efficiency, though, does not care about your security model. It cares about message routing, bandwidth, and timing. These two goals pull in opposite directions, and the mistake most people make is assuming BLS makes the tension disappear.
It doesn't. BLS reduces the verification cost to near-constant regardless of how many validators signed. That's the superpower. But the aggregation cost, collecting, combining, and routing signatures before verification even begins, scales with the number of signers. You cannot BLS-aggregate your way out of a routing problem. That's not pessimism; it's just how pipes work.
Ethereum's research community has been circling this for years. Proposals like single-slot finality (SSF) would collapse the 32-slot epoch into one slot, which sounds cleaner but actually makes aggregation harder: you'd need all active validators to attest in 12 seconds instead of spreading them across an epoch. The current working proposal involves nested aggregation trees, where aggregators aggregate other aggregators' outputs, adding latency but keeping per-node bandwidth fixed regardless of validator count. Whether that holds at 1,000,000-plus validators is an open empirical question, not a settled one.
The Number That Actually Matters
If you want a single figure to anchor your intuition: Ethereum's consensus spec targets a maximum of roughly 2,048 validators per committee. When the active set grows large enough that committees would exceed this, the epoch length or committee structure gets adjusted. This cap exists precisely to bound the aggregation workload per subnet.
Below that cap, adding validators mostly increases security without degrading aggregation. Above it, the spec needs to adapt or the aggregation pipeline starts showing its seams.
The validator set has grown substantially since the Merge, driven by staking demand and liquid staking protocols. Watching whether the community adjusts committee parameters in response is one of the more technically honest ways to track whether Ethereum's consensus layer is scaling gracefully or quietly papering over cracks.
BLS signatures are genuinely brilliant cryptography. A tool, not a solution. The aggregation architecture built around them is what determines whether 500,000 validators or 1,000,000 validators produces a consensus layer that's tight and fast, or one that's technically functional but perpetually one bad slot away from a bad day. The cryptography is solved. The distributed systems problem is still being worked out in real time, by people who are very aware that elegant math and reliable infrastructure are not the same thing.