Mr. F was here. And many more too.
Before we begin, remember that the beacon chain is composed of blocks, each of which contains up to 128 aggregates. These aggregates are “vote summaries”, where each aggregate summarises the votes (attestations) of all members of a committee. Each epoch, validators are assigned to exactly one committee. An epoch is divided further into 32 slots, each slot being assigned several committees.
We’ll often provide examples in the following format. Each row is an aggregate attestation.
Let’s dissect it.
slotis the inclusion slot of the aggregate, i.e., the slot of the block which contains the aggregate. Note that an aggregate may be included multiple times (we’ll look at this below).
att_slotis the attestation slot of the aggregate. The aggregate summarises votes from one committee of a slot, called the attestation slot.
committee_indexis the index of the committee the aggregate summarises votes from.
beacon_blockis the root of the beacon block validators have voted for. Validators are expected to include in their attestation their best estimate of the current head of the chain following the GHOST fork choice rule. They are rewarded if the
beacon_blockin their vote corresponds to the head.
source_blockis the root of the source checkpoint. To provide finality under the Friendly Finality Gadget (FFG) rules, validators include a reference to the source checkpoint, the last justified boundary block of an epoch (either the first block of an epoch or, if it is missing, the last block since).
target_blockis the root of the target checkpoint. Effectively validators draw a link between the source and the target checkpoints, indicating that the target should be the next justified epoch.
attesting_indicesis the voting summary. In the example above, we look at a committee of 3 validators (there are 3 digits in
101indicates that the aggregates contains a vote for the attributes above (attestation slot, committee index, beacon block, source and target blocks) from validators at indices
2of the committee. Note that the validator at index
1could have also published the same vote, but too late for aggregators to pick it up and include it in the summary.
We compare the number of included attestations with the number of expected attestations. Since each (active) validator is expected to attest exactly once per epoch, this also charts the percentage of validators attesting over time.
How many blocks are there in the canonical chain? Validators are sampled randomly to produce blocks. If they fail to produce one, the block is missing. They also sometimes produce one but the block is orphaned, i.e., the chain continues on a different block. The plot below charts the proportion of included blocks to expected blocks.