Phase 1 shard blocks checklist

[vbuterin]

1. 1. Consider removing the List[ShardAttestation] structure in a shard block header, replace with a single shard attestation (rationale: these votes are not used for finalization and the penalties for missing votes are light, so it's okay if more votes "fall by the wayside"; this increases simplicity and makes the shard attestation constant-sized)
   • PR Attestation changes + persistent committee changes #1294
2. 2. Figure out persistent committee structure (per-slot committee size, how far attesters are expected to check availability/validity, are there penalties...)
   • Shard persistent committee selection #1293 discussion, leaning to the simplest option
3. 3. Fix shard block size
   • 16 kb target, 64 kb max
4. 4. Fix crosslink data function, deal with contiguous zero byte segments (see discussion at Inefficiencies in data availability proofs #1194), also consider alternatives to directly putting SSZ serialized header into crosslink data (maybe express the header as chunks in the same order they would be in an SSZ partial?)
   • PR Alternative crosslink data construction, take 1 #1278 PR
5. 5. Determine if top-level EE transaction format influences shard data structure; if so implement any related required changes
   • Instinct currently leans toward "no, add it in phase 2 if needed"
6. 6. Formalize the notion of tight coupling (if a beacon chain includes a crosslink that points to invalid / unavailable shard block data, at what point does it become "invalid"?)
7. 7. Figure out shard rewards, figure out how the portion of shard state used to save shard rewards works
   • Not yet done. Pending agreement that making a minimal shard state that contains a list of reward balances for each period committee and syncing it into the beacon chain every period (day?) is a good idea.
8. 8. Fix shard slot time
   • 3 seconds (half of SECOND_PER_SLOT)
9. 9. Fix shard -> beacon chain lookback mechanics
   • Need to decide between: (i) N slot lookback (eg. N = 4), (ii) one-epoch lookback and (iii) lookback to last finalized chain. I'm leaning toward (i) because otherwise light clients that use persistent committees would be unusable.
10. 10. Explore other simplifications

[djrtwo]

generally agreed on single shard attestation. Would we restrict it to be only a single aggregate from the prior slot?

will provide some more feedback on other points tmw

[vbuterin]

Would we restrict it to be only a single aggregate from the prior slot?

Yeah, this is my thinking.

[vbuterin]

1. Attestation changes + persistent committee changes #1294
2. Need to decide, see Shard persistent committee selection #1293
3. Currently leaning 16 kb target, 64 kb max
4. Alternative crosslink data construction, take 1 #1278
5. Instinct currently leans toward "no, add it in phase 2 if needed"
6. Pending discussion of Edge case: crosslinks de-finalizing #1277; if crosslink restriction is adopted, then the spec is simple, run the epoch-finalization crosslink function, make sure all roots point in the state represent available data, if they do then the block is fine
7. Not yet done. Pending agreement that making a minimal shard state that contains a list of reward balances for each period committee and syncing it into the beacon chain every period (day?) is a good idea.
8. 3 seconds
9. Need to decide between: (i) N slot lookback (eg. N = 4), (ii) one-epoch lookback and (iii) lookback to last finalized chain. I'm leaning toward (i) because otherwise light clients that use persistent committees would be unusable.
10. This item is by definition open until Sep 30 :)

[hwwhww]

Replaced by #1768