Honest validators

[mratsim]

Implement: https://github.com/ethereum/eth2.0-specs/blob/v0.10.1/specs/phase0/validator.md

Improve testing coverage of block pool and validator pool

[tersec]

Prerequisites

• Implement the defined constants.

Becoming a validator

• A validator must initialize many parameters locally before submitting a deposit and joining the validator registry.

• Validator public keys are G1 points on the BLS12-381 curve. A private key, privkey, must be securely generated along with the resultant pubkey.

• A secondary withdrawal private key, withdrawal_privkey, must also be securely generated along with the resultant withdrawal_pubkey.

• In Phase 0, all incoming validator deposits originate from the Ethereum 1.0 proof-of-work chain. Deposits are made to the deposit contract located at DEPOSIT_CONTRACT_ADDRESS.

• Deposits cannot be processed into the beacon chain until the Eth1 block in which they were deposited or any of its descendants is added to the beacon chain state.eth1_data.

• Once a validator has been processed and added to the beacon state's validators, the validator's validator_index is defined by the index into the registry at which the ValidatorRecord contains the pubkey specified in the validator's deposit.

• 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).

Validator assignments

• A validator can get committee assignments for a given epoch using the following helper via get_committee_assignment(state, epoch, validator_index) where epoch <= next_epoch.

• A validator can use is_proposer(...) 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.

Beacon chain responsibilities

• A validator is expected to propose a SignedBeaconBlock at the beginning of any slot during which is_proposer(state, validator_index) returns True. To propose, the validator selects the BeaconBlock, parent, that in their view of the fork choice is the head of the chain during slot - 1. The validator creates, signs, and broadcasts a block that is a child of parent that satisfies a valid beacon chain state transition.

• A validator should create and broadcast the attestation to the associated attestation subnet when ... (b) one-third of the slot hash transpired (SECONDS_PER_SLOT / 3 seconds after the start of slot).

• First, the validator should construct attestation_data, an AttestationData object based upon the state at the assigned slot.

• Next, the validator creates attestation, an Attestation object.

• Finally, the validator broadcasts attestation to the associated attestation subnet -- the index{attestation.data.index % ATTESTATION_SUBNET_COUNT}_beacon_attestation pubsub topic.

• Some validators are selected to locally aggregate attestations with a similar attestation_data to their constructed attestation for the assigned slot.

How to avoid slashing

• In Phase 0, as long as the validator does not sign two different beacon blocks for the same epoch, the validator is safe against proposer slashings.

• To avoid "attester slashings", a validator must not sign two conflicting AttestationData objects, i.e. two attestations that satisfy `is_slashable_attestation_data(...).

[tersec]

#497 (comment) is blocking attestation aggregation.

[tersec]

Closing in favor of #758 for March milestone and for the separate attestation aggregation bug for that part.