# Ethereum 2.0 Validator Notes ### Responsibilities of a Validator The `validator` is then responsible for 1. Checking that new blocks propagated over the network are valid. 2. Create an `attestation` as a vote for block validity. 3. Sign & broadcast `attestation` in every epoch (6.4 minutes). 4. Propose blocks if the `validator` is chosen as a block proposers. 5. Participating in `Sync committees`. ### Why do we need validators ? The purpose of the `attestation` is to vote in favor of the validator's view of the chain, in particular the most recent justified block and the first block in the current epoch. ### Components of a validator attestation 1. `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) 2. `Data` 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 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 3. `Signature` A BLS signature that aggregates the signatures of individual validators Once the data is built, the validator can flip the bit in aggregation_bits corresponding to their own validator index from 0 to 1 to show that they participated. Finally, the validator signs the attestation and broadcasts it to the network. ### Validator Roles (Verify!) 1. `Aggregator validators` In each epoch a validator in each subnet is selected to be the aggregator. The aggregator collects all the attestations it hears about over the gossip network that have equivalent data to its own 2. `Block Proposer validator` When a validator is selected to be a block proposer they package aggregate attestations from the subnets up to the latest slot in the new block. ### Rewards Calculation Validators are rewarded for submitting attestations. 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 equal to 1. `attestation reward = 7/8 x base reward x (1/inclusion delay)` ### Edge-cases 1. `Missing Voting Validator` 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. 2. `Missing Aggregator` There are 16 Aggregators per epoch in total. In addition, random validators subscribe to two subnets for 256 epochs and serve as a backup in case aggregators are missing. 3. `Missing block proposer` 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.