Exploring the first 1000 epochs of eth2

Mr. F was here. And many more too.

Barnabé Monnot https://twitter.com/barnabemonnot (Robust Incentives Group, Ethereum Foundation)https://github.com/ethereum/rig
2020-12-07

We look at data between epochs 0 and 1000 (2020-12-05 22:40:23 UTC) and report updated metrics for eth2’s mainnet. You can also find a similar notebook for Medalla here and Pyrmont here.

Performance of duties

Anatomy of an aggregate

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.

• slot is 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_slot is the attestation slot of the aggregate. The aggregate summarises votes from one committee of a slot, called the attestation slot.
• committee_index is the index of the committee the aggregate summarises votes from.
• beacon_block is 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_block in their vote corresponds to the head.
• source_block is 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_block is 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_indices is the voting summary. In the example above, we look at a committee of 3 validators (there are 3 digits in attesting_indices). 101 indicates that the aggregates contains a vote for the attributes above (attestation slot, committee index, beacon block, source and target blocks) from validators at indices 0 and 2 of the committee. Note that the validator at index 1 could have also published the same vote, but too late for aggregators to pick it up and include it in the summary.

Attester duties

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.

Proposer duties

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.