Initial shard slot number

[hwwhww]

Issue

Currently, the initial shard state slot is set to PHASE_1_GENESIS_SLOT by setting shard_state.slot = pre.slot

For example, if PHASE_1_GENESIS_SLOT is 32:

The shard block 32 cannot exist and both B_32 and B_33 point to initial shard state.

How to fix it

IMO the scenario would be neater if we set initial shard slot to compute_previous_slot(pre.slot).

[hwwhww]

/cc @djrtwo @protolambda

[djrtwo]

This does seem reasonable, but one thing we need to be careful about is that for a system that is started from Phase 1 a GENESIS_SLOT, the shard states at B0 would be for slot 0 (because of how compute_previous_slot handles 0 input.

I do expect some systems to want to start phase 1 from slot 0 so we should at least ensure that nothing is broken here. OR we put some sort of requirement taht PHASE_1_GENESIS_SLOT is at least GENESIS_SLOT + SLOTS_PER_EPOCH

[mkalinin]

This does seem reasonable, but one thing we need to be careful about is that for a system that is started from Phase 1 a GENESIS_SLOT, the shard states at B0 would be for slot 0 (because of how compute_previous_slot handles 0 input.

I have this particular kind of setup (PHASE_1_GENESIS_SLOT = GENESIS_SLOT = 0). The following list of patches did help to sort the things out:

• get_shard_transition returns empty shard transition if GENESIS_SLOT
• validate_attestation allows for empty shard transition root if GENESIS_SLOT
• process_shard_transitions skips crosslink processing if compute_previous_slot(state.slot) == GENESIS_SLOT