fix up validator guide crosslink committee instructions #1085
Conversation
|
|
||
| ### 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 checked during the slot in question. |
There was a problem hiding this comment.
"Note that this lookahead does not apply to proposing, which must checked during the slot in question." => This is no longer true with the latest validator.effective_balance logic.
There was a problem hiding this comment.
Still does not provide a 1 epoch lookahead. It is instead just within the epoch in question
| return get_beacon_proposer_index(state) == validator_index | ||
| ``` | ||
|
|
||
| *Note*: To see if a validator is assigned to proposer during the slot, the validator must run an empty slot transition from the previous state to the current slot using `process_slots(state, current_slot)`. |
There was a problem hiding this comment.
Transitioning to the previous slot is no longer required (see other comment).
There was a problem hiding this comment.
ah, right. balance only changes at epoch's right?
There was a problem hiding this comment.
gotcha. effective_balance is only adjusted at epoch boundaries. A few things still change balance but it isn't cleaned up against effective_balance until the boundaries.
This is a good invariant to note. from state_A -> state_b all effective_balances are unchanged unless state_A -> state_B is an epoch change.
| ## Beacon chain responsibilities | ||
|
|
||
| A validator has two primary responsibilities to the beacon chain: [proposing blocks](#block-proposal) and [creating attestations](#attestations-1). Proposals happen infrequently, whereas attestations should be created once per epoch. | ||
|
|
||
| ### Block proposal | ||
|
|
||
| A validator is expected to propose a [`BeaconBlock`](../core/0_beacon-chain.md#beaconblock) at the beginning of any slot during which `get_beacon_proposer_index(state)` returns the validator's `validator_index`. 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 is to create, sign, and broadcast a `block` that is a child of `parent` and that executes a valid [beacon chain state transition](../core/0_beacon-chain.md#beacon-chain-state-transition-function). | ||
| A validator is expected to propose a [`BeaconBlock`](../core/0_beacon-chain.md#beaconblock) 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 is to create, sign, and broadcast a `block` that is a child of `parent` and that executes a valid [beacon chain state transition](../core/0_beacon-chain.md#beacon-chain-state-transition-function). |
There was a problem hiding this comment.
"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." => This can be better formalised with the new executable fork choice (see get_head in #1068).
| ## Beacon chain responsibilities | ||
|
|
||
| A validator has two primary responsibilities to the beacon chain: [proposing blocks](#block-proposal) and [creating attestations](#attestations-1). Proposals happen infrequently, whereas attestations should be created once per epoch. | ||
|
|
||
| ### Block proposal | ||
|
|
||
| A validator is expected to propose a [`BeaconBlock`](../core/0_beacon-chain.md#beaconblock) at the beginning of any slot during which `get_beacon_proposer_index(state)` returns the validator's `validator_index`. 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 is to create, sign, and broadcast a `block` that is a child of `parent` and that executes a valid [beacon chain state transition](../core/0_beacon-chain.md#beacon-chain-state-transition-function). | ||
| A validator is expected to propose a [`BeaconBlock`](../core/0_beacon-chain.md#beaconblock) 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 is to create, sign, and broadcast a `block` that is a child of `parent` and that executes a valid [beacon chain state transition](../core/0_beacon-chain.md#beacon-chain-state-transition-function). |
There was a problem hiding this comment.
"The validator is to create, sign, and broadcast a block that is a child of parent and that executes a valid beacon chain state transition."
"create, sign" is redundant given "that executes a valid state transition".
There was a problem hiding this comment.
When validating, creating a block and then signing the block are separate actions. All clients have an option to run the state transition without verifying signatures because you can't have a valid signature until you've run the block transition.
I'll try to clean this up a little.
Co-Authored-By: Hsiao-Wei Wang <hwwang156@gmail.com>
addresses #1082