From 9742b3a1571969a7dfe8bcb8e5fb604956deb9e7 Mon Sep 17 00:00:00 2001 From: Danny Ryan Date: Wed, 19 Aug 2020 09:58:02 -0600 Subject: [PATCH] clarify what 'state' is for block proposals in validator guide --- specs/phase0/validator.md | 30 +++++++++++++++++++++++++----- 1 file changed, 25 insertions(+), 5 deletions(-) diff --git a/specs/phase0/validator.md b/specs/phase0/validator.md index e379df03c..a18d07600 100644 --- a/specs/phase0/validator.md +++ b/specs/phase0/validator.md @@ -194,9 +194,14 @@ def is_proposer(state: BeaconState, validator_index: ValidatorIndex) -> bool: ### Lookahead -The beacon chain shufflings are designed to provide a minimum of 1 epoch lookahead on the validator's upcoming committee assignments for attesting dictated by the shuffling and slot. Note that this lookahead does not apply to proposing, which must be checked during the epoch in question. +The beacon chain shufflings are designed to provide a minimum of 1 epoch lookahead +on the validator's upcoming committee assignments for attesting dictated by the shuffling and slot. +Note that this lookahead does not apply to proposing, which must be checked during the epoch in question. -`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 at which future slot they will have to attest and joining the committee index attestation subnet related to their committee assignment. +`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 at which future slot +they will have to attest and joining the committee index attestation subnet related to their committee assignment. Specifically a validator should: * Call `get_committee_assignment(state, next_epoch, validator_index)` when checking for next epoch assignments. @@ -214,9 +219,18 @@ A validator has two primary responsibilities to the beacon chain: [proposing blo ### Block proposal -A validator is expected to propose a [`SignedBeaconBlock`](./beacon-chain.md#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](./beacon-chain.md#beacon-chain-state-transition-function). +A validator is expected to propose a [`SignedBeaconBlock`](./beacon-chain.md#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](./beacon-chain.md#beacon-chain-state-transition-function). -There is one proposer per slot, so if there are N active validators any individual validator will on average be assigned to propose once per N slots (e.g. at 312,500 validators = 10 million ETH, that's once per ~6 weeks). +There is one proposer per slot, so if there are N active validators any individual validator +will on average be assigned to propose once per N slots (e.g. at 312,500 validators = 10 million ETH, that's once per ~6 weeks). + +*Note*: In this sectio, `state` is the state of the slot for the block proposal _without_ the block yet applied. +That is, `state` is the `previous_state` processed through any empty slots up to the assigned slot using `process_slots(previous_state, slot)`. #### Preparing for a `BeaconBlock` @@ -251,7 +265,13 @@ def get_epoch_signature(state: BeaconState, block: BeaconBlock, privkey: int) -> ##### Eth1 Data -The `block.body.eth1_data` field is for block proposers to vote on recent Eth1 data. This recent data contains an Eth1 block hash as well as the associated deposit root (as calculated by the `get_deposit_root()` method of the deposit contract) and deposit count after execution of the corresponding Eth1 block. If over half of the block proposers in the current Eth1 voting period vote for the same `eth1_data` then `state.eth1_data` updates immediately allowing new deposits to be processed. Each deposit in `block.body.deposits` must verify against `state.eth1_data.eth1_deposit_root`. +The `block.body.eth1_data` field is for block proposers to vote on recent Eth1 data. +This recent data contains an Eth1 block hash as well as the associated deposit root +(as calculated by the `get_deposit_root()` method of the deposit contract) and +deposit count after execution of the corresponding Eth1 block. +If over half of the block proposers in the current Eth1 voting period vote for the same +`eth1_data` then `state.eth1_data` updates immediately allowing new deposits to be processed. +Each deposit in `block.body.deposits` must verify against `state.eth1_data.eth1_deposit_root`. ###### `Eth1Block`