The attestation reward is dependent on two variables, the base reward and the inclusion delay. The best case for the inclusion delay is to be 1.
(Validator effective balance * 2**6) / SQRT(Effective balance of all active validators)
At the time when the validators voted on the head of the chain (Block 0),
Block 1 was not proposed yet.
Therefore attestations naturally get included one block later; so all attestations who voted on
Block 0 being the chain head got included in
Block 1 and, the inclusion delay is 1.
As shown below, an Inclusion delay of 2 causes the the reward to drop by 50%.
These validators have a maximum of 1 epoch to submit their attestation. If the attestation was missed in epoch 0, they can submit it with an inclusion delay in epoch 1.
There are 16 Aggregators per epoch in total, additionally, random validators from the beacon-chain subscribe to two subnets for 256 Epochs and serve as a backup in case aggregators are missing.
Note that in some cases a lucky aggregator may also become the block proposer. If the attestation was not included because the block proposer has gone missing, the next block proposer would pick the aggregated attestation up and include it into the next block. However, the inclusion delay will increase by one.
Let's look at the example below.
The attestation for
slot 156508 was included in
slot 156510 but why is the inclusion distance 0?
If were to use the formula from above and set the inclusion delay to 0, the rewards would be 0 for a proposed attestation.
Missed blocks are not added to the inclusion distance, but since the attestant is not responsible for the block proposal, and to only warn the user about its faults (e.g. slow internet connection, power failure etc.), the beaconcha.in explorer displays the distance as 0.