Attestations

A validator must create, sign, and broadcast an attestation during every epoch. Hence, for every epoch (6.4 minutes), a validator proposes an attestation to the network. The attestation is for a specific slot in the epoch. The purpose of the attestation is to vote in favor of the validator's view of the chain, particularly the most recent justified block and the first block in the current epoch (known as source and target checkpoints). This information is combined with all participating validators (sync commitee), enabling the network to reach a consensus about the state of the blockchain.

The attestation contains the following components:

• aggregation_bits: a bitlist of validators where the position maps to the validator index in their committee; the value (0/1) indicates whether the validator signed the data (i.e. whether they are active and agree with the block proposer)

• data: details relating to the attestation, as defined below

• signature: a BLS signature that aggregates the signatures of individual validators

The first task for an attesting validator is to build the data. The data contains the following information:

• slot: The slot number that the attestation refers to

• index: A number that identifies which committee (see light clients/light synchronization) the validator belongs to in a given slot

• beacon_block_root: Root hash of the block the validator sees at the head of the chain (the result of applying the fork-choice algorithm)

• source: Part of the finality vote indicating what the validators see as the most recent justified block

• target: Part of the finality vote indicating what the validators see as the first block in the current epoch

Once the data is built, the validator can flip the bit in aggregation_bits corresponding to their validator index from 0 to 1 to show that they participated. Finally, the validator signs the attestation and broadcasts it to the network.

Aggregated attestation

A substantial overhead is associated with passing this data around the network for every validator. Therefore, the attestations from individual validators are aggregated within subnets before being broadcast more widely. This includes aggregating signatures so that an attestation that gets broadcast includes the consensus data and a single signature formed by combining the signatures of all the validators that agree with that data. This can be checked using aggregation_bits because this provides the index of each validator in their committee (whose ID is provided in data), which can query individual signatures.

In each epoch, 16 validators in each subnet are selected to be the aggregators. The aggregators collect all the attestations they hear about over the gossip network with equivalent data to their own. The sender of each matching attestation is recorded in the aggregation_bits. The aggregators then broadcast the attestation aggregate to the broader network.

When a validator is selected as block proposer, they package aggregate attestations from the subnets up to the latest slot in the new block.

Attestation inclusion lifecycle

The Ethereum and Nephele networks employ a structured attestation inclusion lifecycle to enhance its Proof-of-Stake consensus mechanism. This lifecycle is crucial for ensuring network integrity and security through validator participation. Here’s a simplified breakdown of the stages involved:

1. Generation: This initial stage involves validators creating attestations. These attestations serve as votes for a particular blockchain view, indicating the validator's agreement with the state of a proposed block and its position within the blockchain.

2. Propagation (First Stage): Attestations are disseminated through the network after generation. This ensures that the information reaches other validators and serves as a preparatory step for the next phase of aggregation.

3. Aggregation: Due to the large volume of attestations generated by individual validators, they are aggregated to form a collective attestation. This process is facilitated by designated validators known as aggregators, who combine multiple individual attestations into a single comprehensive attestation, optimizing network bandwidth and reducing computational load.

4. Propagation (Second Stage): The aggregated attestation is then propagated to the wider network. This step is critical for ensuring that the aggregated attestation reaches the block proposer effectively.

5. Inclusion: Finally, the block proposer includes the aggregated attestation in an upcoming block. This inclusion is vital for the blockchain's consensus process, as it represents a collective agreement on the state of the blockchain as observed by multiple validators.

Each step of this lifecycle plays a pivotal role in the Ethereum network’s operation, enhancing its security and efficiency. Validators are incentivized through rewards to participate actively and correctly in this process. The system is designed to minimize the possibility of errors and ensure that only valid and agreed-upon information is recorded on the blockchain.

The attestation lifecycle is outlined in the schematic below: