add lookahed for shard subnets for beacon committee in validator guide

This commit is contained in:
Danny Ryan 2020-04-03 08:33:32 -06:00
parent d61b2991a0
commit f135eff021
No known key found for this signature in database
GPG Key ID: 2765A792E42CE07A
1 changed files with 9 additions and 0 deletions

View File

@ -15,6 +15,7 @@
- [Misc](#misc)
- [Becoming a validator](#becoming-a-validator)
- [Beacon chain validator assignments](#beacon-chain-validator-assignments)
- [Lookahead](#lookahead)
- [Beacon chain responsibilities](#beacon-chain-responsibilities)
- [Block proposal](#block-proposal)
- [Preparing for a `BeaconBlock`](#preparing-for-a-beaconblock)
@ -83,6 +84,14 @@ Becoming a validator in Phase 1 is unchanged from Phase 0. See the [Phase 0 vali
Beacon chain validator assignments to beacon committees and beacon block proposal are unchanged from Phase 0. See the [Phase 0 validator guide](../phase0/validator.md#validator-assignments) for details.
### Lookahead
Lookahead for beacon committee assignments operates in the same manner as Phase 0, but committee members must join a shard block pubsub topic in addition to the committee attestation topic.o
Specifically _after_ finding stable peers of attestation subnets (see Phase 0) a validator should:
* Let `shard = compute_shard_from_committee_index(committe_index)`
* Subscribe to the pubsub topic `shard_{shard}_shard_block` (attestation subnet peers should have this topic available).
## 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.