# Why are there between 64 and 128 attestations every slot if there's only 64 committees?

Every slot have between 64 to 128 attenstations but all only have 64 committees. Some of the attestations on slots are done by 128+ validators of one committees while another attestation could be done by a single validator of the same committee. Why?

Example: Slot 2969389 Attenstation #6 consist of only validator #58027 of committee #26 Attenstation #68 however consist of the rest of the validators of committee #26 https://beaconcha.in/block/2969389#attestations

In attestation #6, validator 58027 voted for block `0xd200f8...` as the head. In attestation #68 the rest of the committee voted for `0x8eca26...` as the head. Since `0xd200f8...` is the parent of `0x8eca26...` it seems that validator 58027 did not see `0x8eca26...` in time before it made its attestation, so it thought that slot 2969388 was empty and voted accordingly.

The proposer at slot 2969389 had extra space in its block, so it managed to include both attestations, though the single attestation is not worth much, especially as its head vote is wrong.

The main reason that 128 slots were made available although there are only 64 committees is to allow the beacon chain to catch up after a skipped slot.

Now that we have over 262,144 active validators, there are 64 committees per slot. In the ideal case there will be a single high-value aggregate attestation (one that most committee members have signed-off on) per committee. Thus we expect 64 high value aggregate attestations per slot, plus maybe a few stray low-value attestations (late or attesting to a minority fork) that the proposer can add in for some extra small reward.

After a skipped slot (one with no block) there will be 64 high value aggregate attestations from that slot plus 64 from the current slot floating around. Being able to include 128 aggregates in a block means that almost no consensus information is lost due to a single skipped slot.

Interestingly, this means that a block immediately after a skipped slot can be worth 71.4% more than a regular block as it can include many more valuable aggregate attestations (it's not worth double, because the correct head reward is forfeit for attestations over one slot old).

Per specification, there are 128 maximum attestations per block.

For various reasons, not all slots have at least 64 attestations: for example slot 2 only has 19.

But block proposers get more rewards the more validator attestations that they include in a block. So ideally, yes, it is expected that a slot would have equal number of attestations to committees, with each attestation including all the validators in that committee.

Some of the attestations on slots are done by 128+ validators of one committees while another attestation could be done by a single validator of the same committee. Why?

In each committee, there are 16 aggregators. Validator (BLS12-381) signatures are aggregated (per committee) so that ideally 16 (aggregate) signatures can be on-chain instead of a signature per validator. A Beacon Chain client can only aggregate what it knows about in time. Sometimes a client can aggregate perfectly, which is when you see 128+ validators of one committee. Sometimes a validator is late in propagating their attestation, so when a client gets it, there is no aggregation it can do.

• Great answer, but how is it even possible to have in perfect case only 1 aggregated attestation per committee since every committee has 16 aggregators - wouldn't that make 16 aggregated attestations and not one? Or are those 16 aggregated further into only one? Commented Oct 16, 2022 at 16:38
• @BokiXD You are totally right, there's 16 aggregators and signatures. I edited the answer to mention the aggregators.
– eth
Commented Oct 20, 2022 at 2:35
• No worries! But still, there is preferably only one attestation per committee - the GitHub technical spec. does not go in detail how we go from 16 aggregations to only one, but here is how I understood it: There is also aggregation done at the block proposer's side where they aggregate again those 16 aggregations to hopefully reach only one aggregated attestation. The tricky part is that there should not be any single validator's attestation present in two different aggregations - thus one of the main issues block proposer has to face is how to... Commented Oct 21, 2022 at 10:25
• ... aggregate as many aggregations without overlap in attestations. Am I correct here? And as far as I understood it, every client can implement that logic for "smart way" of aggregating as they want - since I didn't fine only one aggregation strategy. Commented Oct 21, 2022 at 10:26
• @BokiXD Understand your question and I did not know that the 16 also gets aggregated by the proposer. Are you on the Ethereum R&D Discord or the consensus client discords? I'm confident someone will be able to answer well, and maybe you can post a new question and self-answer with what you find? :)
– eth
Commented Oct 21, 2022 at 18:16