Phase0 - Honest Validator Flashcards
What are the new constants introduced to describe an Honest Validator?
- TARGET_AGGREGATORS_PER_COMMITTEE = 16 validators
- RANDOM_SUBNETS_PER_VALIDATOR = 1 Subnet
- EPOCHS_PER_RANDOM_SUBNET_SUBSCRIPTION = 256 epochs
- ATTESTATION_SUBNET_COUNT = 64
souce: https://github.com/ethereum/consensus-specs/blob/dev/specs/phase0/validator.md#eth1-data
What are the 3 new data structures that was introduced as part of describing an Honest Validator?
- Eth1Block
- AggregateAndProof
- SignedAggregateAndProof
What are the parameters a validator must initiate locally before submitting a deposit and joining the validator registry?
- BLS public key
- Withdrawal credential
- Amount
- BLS Signature
- Let deposit_message be a DepositMessage with all the DepositData contents except the signature
Source: https://github.com/ethereum/consensus-specs/blob/dev/specs/phase0/beacon-chain.md#depositdata
How is the deposit to join as a validator processed?
- It is processed not until the proof-of-work (eth1) block in which they were deposited or any of its descendants is added to the beacon chain (BeaconState) state.eth1_data
- After this, it is added to state.validators within an epoch or two. The validator is then in a queue to be activated.
- A validator_index is generated
- In normal operation, the validator is quickly activated, at which point the validator is added to the shuffling and begins validation after an additional MAX_SEED_LOOKAHEAD epochs (25.6 minutes)
How does a validator get its assignment? How does it know which committee is it assigned and what slot, what epoch?
It does so by calling get_committee_assignment(state, epoch, validator_index) where epoch <= next_epoch. So for a given state, and epoch and its validator_index it requests the assignment. Which is returned in the form:
Tuple[Sequence[ValidatorIndex], CommitteeIndex, Slot]
Return the committee assignment in the epoch for validator_index.
assignment returned is a tuple of the following form:
* assignment[0] is the list of validators in the committee
* assignment[1] is the index to which the committee is assigned
* assignment[2] is the slot at which the committee is assigned
Return None if no assignment.
How does a validator know it is to propose during a slot?
A validator can use the following function to see if they are supposed to propose during a slot. This function can only be run with a state of the slot in question. Proposer selection is only stable within the context of the current epoch.
def is_proposer(state: BeaconState, validator_index: ValidatorIndex) -> bool:
return get_beacon_proposer_index(state) == validator_index
How far ahead can a validator know its attestation related tasks?
1 epoch away.
get_committee_assignment should be called at the start of each epoch to get the assignment for the next epoch (current_epoch + 1). A validator should plan for future assignments by noting their assigned attestation slot and joining the committee index attestation subnet related to their committee assignment
What are the tasks a validator should perform in preparation of its attestation assignments in the coming epoch?
- call the get_committee_assignment to get the list of validators in its committee, the committee index, and the slot it belongs to
- It then derive the pubsub topic of beacon_attestation_{subnet_id}
- It then find peers of the pubsub topic of beacon_attestation_{subnet_id}
When a validator needs to prepare for its attestion assignment in the coming epoch it derives a subnet_id and use this to find the peers of the pubsub topic beacon_attestation_{subnet_id}.
How is this subnet_id calculated?
- Calculate the committees per slot for the next epoch: committees_per_slot = get_committee_count_per_slot(state, next_epoch)
- Calculate the subnet_index from the committees per slot. That is Calculate the subnet index: subnet_id = compute_subnet_for_attestation(committees_per_slot, slot, committee_index)
What does a validator needs before it can publish attestation messages?
Validator only needs to connect to sufficient number of peers on the topic (beacon_attestation_{subnet_id}) to be able to publish messages.
How much is sufficient? Don’t know yet
How does a validator discover new peers if there are insufficient peers on the beacon_attestation_{subnet_id}?
If an insufficient number of current peers are subscribed to the topic, the validator must discover new peers on this topic. Via the discovery protocol, find peers with an ENR containing the attnets entry such that ENR[“attnets”][subnet_id] == True. Then validate that the peers are still persisted on the desired topic by requesting GetMetaData and checking the resulting attnets field
If a validator is also an aggregator, what other step does it have to take apart from finding peers on the beacon_attestation_{subnet_id} topic?
If the validator is assigned to be an aggregator for the slot (see is_aggregator()), then subscribe to the beacon_attestation_{subnet_id} topic.
What are the primary responsibilities a validator has to the beacon chain?
A validator has two primary responsibilities to the beacon chain: proposing blocks and creating attestations. Proposals happen infrequently, whereas attestations should be created once per epoch.
