phase 1 validator guide (round 1)

[djrtwo]

Add phase 1 validator guide.

Add the following checked items. Leave the remaining for a subsequent PR(s)

• Block proposal
• Attesting
  • Join shard block subnet in addition to attestation subnet
  • On-time attestation
    • Attestation data
    • Add custody bits blocks [Waiting on custody rewrite 0.01 bit proof of custody [depends on 256 bit custody atoms] #1889]
    • Compute signature
    • aggregation
  • Late attestation (no custody_bits_blocks, stub shard_transition, when to broadcast, when to aggregate)
  • [Think about] Split shard_transition from attestation_data in p2p for deduplication gains (OR split attestation_data from attestation...)
• Light client committee
  • clean up beacon chain spec and add validator duties
• Shard duties
  • Persistent committee subnets and lookahead (replacement for random subnets)
  • Shard block creation and broadcast
• Additional slashing avoidance

[djrtwo]

@hwwhww I moved get_shard_transition from shard-transition.md to the validator guide (I think the appropriate place).

I also greatly reduced the complexity of what is going on here. I think previously, much of the helper functions were implementing some weird version of the fork choice. Now, we assume that shard_blocks is the already validated sequence of blocks received from the fork choice leading to the current head of the shard chain.

One important thing is that I am currently assuming that the fork choice is only going to give me heads of chains that fit the expected offset_slots. The forkchoice doesn't currently provide this safety mechanism, but I think that it probably should.

Can you take a look at this attestation data section (mainly the mods I made to get_shard_transition) and the proposed addition of offset_slots being enforced by fork choice? Happy to hop on a quick call to help you go over this and discuss in more depth

[hwwhww]

Good points!

Added changes at #1773

1. Added rules to enforce the shard block is at offset slots 49cbc7c
2. Added get_pending_shard_blocks helper that returns the shard_blocks at offset slots till head beacon slot: 465f230 returns correct data.

[hwwhww]

Great work!! ✨

I reviewed the shard transition part. will review other parts later.

[hwwhww]

Good points!

Added changes at #1773

1. Added rules to enforce the shard block is at offset slots 49cbc7c
2. Added get_pending_shard_blocks helper that returns the shard_blocks at offset slots till head beacon slot: 465f230 returns correct data.

[hwwhww]

Followup note of #1704 (comment):

These are some cases I see for attesting shard_block_100 and shard_block_101:

If head_state is transitioned to the slot of current time, Slot(state.slot + 1) works for these cases. Any other case I missed?

EDIT: added more lines

[terencechain]

Followup note of #1704 (comment):

These are some cases I see for attesting shard_block_100 and shard_block_101:
If head_state is transitioned to the slot of current time, Slot(state.slot + 1) works for these cases. Any other case I missed?

Do you consider 4a and 4b as 2 different cases? If yes, does it break current transition?

4a: B100 crosslinks S99
4b: B100 did not crosslinks S99, B101 crosslinks S99.

[hwwhww]

@terencechain

Thank! It looks like an extended case!
I wanted to use "B100 crosslinks S99" to represent "the latest crosslink at the beginning". Rewrite it to:

[hwwhww]

Another round :)

[hwwhww]

Updated the domain types table a bit.

LGTM except for an is_in_next_light_client_committee question.
Good job! 💯

[hwwhww]

The input epoch of get_light_client_committee should be the epoch that the light clients have to vote for, not the source epoch.

I suppose it should be:

Suggested change

	current_source_epoch = compute_committee_source_epoch(get_current_epoch(state), LIGHT_CLIENT_COMMITTEE_PERIOD)
	next_source_epoch = current_source_epoch + LIGHT_CLIENT_COMMITTEE_PERIOD
	next_committee = get_light_client_committee(state, next_source_epoch)
	next_committee = get_light_client_committee(state,get_current_epoch(state) + LIGHT_CLIENT_COMMITTEE_PERIOD)

[djrtwo]

I'd actually argue that the above logic is the same, and I considered writing it as you had originally but wasn't sure if the logic was clear.

Making the change regardless. (curious if I am incorrect in saying that you'll get the same result either way)

[hwwhww]

@djrtwo
No, they are not the same result. I argued the function logic correctness:

• get_light_client_committee itself will compute the correct source epoch internally, so we don't have to pass the source epoch to it.
• The epoch we pass to get_light_client_committee should have been the epoch that the light client is going to vote for. In this case, setting it to get_current_epoch(state) + LIGHT_CLIENT_COMMITTEE_PERIOD can make it forward to the next period.

[djrtwo]

But getting the current_source_epoch and adding LIGHT_CLIENT_COMMITTEE_PERIOD to it will put you certainly in the next period. Just as get_current_epoch + LIGHT_CLIENT_COMMITTEE_PERIOD will also put you in the next period

[hwwhww]

But getting the current_source_epoch and adding LIGHT_CLIENT_COMMITTEE_PERIOD to it will put you certainly in the next period. Just as get_current_epoch + LIGHT_CLIENT_COMMITTEE_PERIOD will also put you in the next period

No, because compute_committee_source_epoch(epoch, period) has a lookahead inside and get_light_client_committee(beacon_state, epoch) already calls compute_committee_source_epoch(epoch, LIGHT_CLIENT_COMMITTEE_PERIOD) internally. So current_source_epoch + LIGHT_CLIENT_COMMITTEE_PERIOD is the next_source_epoch point at the diagram below, then get_light_client_committee(next_source_epoch) would output the committee of period 2. I believe we want to get the committee of period 3, right?