Attesting Blocks and Committees

Once a block is proposed, it can be attested by the attestors. Attestors are assigned to committees pseudo-randomly. The randomness is provided by the RANDAO. In Ethereum 2.0, a committee consists of at least 128 validators. Each slot has its own committee. There may be more than one committee per block. As no validator can be part of two committees in one epoch, two committees are possible if there are at least 8,192 validators.

The task of the validators is to vote for what they think is the head of the blockchain. This is the LMD GHOST vote.

Attestors can have different opinions on what the correct head of the chain is. This can be caused by network latency or if the attestor was offline for a while.

Also, attestors can be late with their votes. A delay can be caused by many reasons:

• Attestor is offline
• Attestor has an inaccurate clock
• Workload on the attestor’s computer is too high
• Latency in the network/gossip protocol

Validators are assigned to committees one epoch in advance. This means, At the end of epoch N, the attestors and proposers for epoch N + 2 are chosen.

Each committee has 16 Aggregators. The task of the aggregators is to collect attestations from the committee’s attestors. Then, the aggregators broadcast the aggregated signatures. Finally, the block proposer collects the aggregated attestations from all committees and includes them in his block.

Attestors are supposed to submit their attestation within one slot. If they submit their attestation later (attestation delay), their attestation reward gets reduced. The longer the attestation delay, the lower the reward. Attestors vote on the head of the chain (block 0). But at the time, when they voted, bock 1 was not created yet. So, their attestation can be included earliest in block 2. Hence, the attestation delay is at least 1. With an attestation delay of 1, the attestor receives 100% of its reward. The attestation reward is calculated by the following formula:

The following chart shows how the attestation reward declines with rising attestation delay.

The attestation workflow is as follows:

1. Generation: Attestors collect block data, validate them, and create an attestation signature.
2. Propagation: Attestors send the attestation in a subnet to the aggregators.
3. Aggregation: Aggregators aggregate the attestations from their committee. Each committee has 16 randomly selected aggregators.
4. Propagation: Aggregators send the aggregated attestations to the block proposer.
5. Inclusion: Block proposers receive the aggregated attestations from each aggregator and include them in their block.

The reason for aggregating votes by designated aggregators is to reduce the number of messages sent through the network.

With only 16 aggregators per committee, there is the risk of censoring certain attestations. That’s why it is also possible for attestors to send their votes directly to the proposers. Proposers can add single votes too. The more attestations a proposer includes in their block, the more he gets rewarded.