You're a validator. The epoch ticks over, your committee assignment lands, and somewhere between 127 other validators are doing exactly the same thing at exactly the same moment: signing a vote that says this block is the head of the chain. Now imagine that happening across hundreds of thousands of validators, every 6.4 minutes, forever. Without a compression mechanism, the network would drown in its own bookkeeping before you finished reading this sentence.
That's the core problem Ethereum's attestation aggregation solves. The solution is more elegant than most explainers give it credit for.
One Signature to Rule the Committee
Every epoch, Ethereum's validator set gets shuffled into committees, each assigned to attest to a specific checkpoint. A naive implementation would mean hundreds of thousands of individual signatures propagating through gossip. The bandwidth math is punishing.
Aggregation sidesteps that through BLS signatures, a cryptographic scheme with one genuinely useful property: multiple signatures over the same message can be combined into a single signature no larger than any one of them. You verify that combined signature against the aggregated public key (the mathematical combination of all individual public keys) of all signers, in one pass. The math holds because BLS signatures live in an algebraic group where addition preserves the verification relationship.
Concretely: a committee of 128 validators produces 128 individual attestations. A designated aggregator, selected pseudo-randomly and weighted by effective balance, collects those, folds them into one BLS aggregate signature, attaches a bitfield showing which committee members signed, and broadcasts that single object. The rest of the network receives and verifies one signature instead of 128. The bandwidth reduction is roughly linear in committee size, and across a full epoch with dozens of committees running simultaneously, the savings are substantial.
Think of it like a class photo versus a roll call read aloud. Same information. One takes thirty seconds.
The Bitfield Is Carrying More Weight Than It Appears
Most explanations treat the bitfield as a footnote. It isn't, it's where fault tolerance actually lives.
Each aggregated attestation carries a compact bitmask: one bit per committee slot, set to 1 if that validator's signature is included. This means the network can always count exactly how many validators attested to any given checkpoint and precisely which ones. Nothing is hidden behind the aggregation.
Why does that matter? Ethereum's finality rule, the Casper FFG component (a mechanism requiring supermajority agreement before a checkpoint is considered irreversible), demands that a checkpoint gather attestations from validators controlling at least two-thirds of the total staked ETH before it can be justified. The bitfield lets any node reconstruct the exact participation weight of any aggregate, so the two-thirds threshold can be checked with full precision even though the underlying signatures have been compressed. You compress the cryptographic proof, not the audit trail. That distinction is the whole game.
If an aggregator is malicious or lazy and drops signatures, the missing bits are visible. Other aggregators can fill the gaps. Multiple aggregates for the same slot can be included in a block, their bitfields unioned together, as long as they don't double-count the same validator.
Here's a worked example. Two aggregators, call them A and B, are both assigned to the same committee in slot 42. Aggregator A collects signatures from validators 0 through 79. Aggregator B collects from validators 60 through 127. Their bitfields overlap in positions 60 through 79. A block proposer includes both aggregates, takes the union of non-overlapping bits, and ends up with coverage of all 128 validators, provided the overlapping signatures are consistent. The redundancy is intentional. A single failed or censoring aggregator cannot silently suppress participation.
This is the design judgment worth pausing on: the protocol is explicitly built around the assumption that individual aggregators will sometimes fail, and it treats that as an engineering constraint to route around rather than a problem to eliminate. That's the right instinct.
One Caveat Worth Naming
BLS aggregation only works cleanly when all signatures attest to exactly the same message. Validators who voted for a different block, or in a slightly different slot, cannot be folded into the same aggregate. So in practice, partial non-participation or chain forks produce multiple aggregates floating around gossip simultaneously, and the savings shrink when consensus is contested. The scheme is optimized for the happy path, which is, to be fair, what happens the overwhelming majority of the time.
The aggregator selection mechanism also carries real trust. If the pseudo-random selection is biased or predictable far enough in advance, an attacker could target aggregators specifically. Ethereum's use of RANDAO with lookahead limits (RANDAO being an on-chain randomness beacon that only reveals future values gradually) is meant to keep that window short. It's a live engineering tradeoff, not a closed question.
What you're left with is a system that treats bandwidth as the scarce resource it actually is, sacrifices nothing on the accountability side, and handles the messy edge cases through redundancy rather than perfection. For a network designed to run for decades, that ordering of priorities is exactly correct.