Proposed refactor of compact committees

[vbuterin]

NOT substantive.

Goal is to abstract out the committee to compact committee transformation to allow it to be used for persistent committees as well.

[JustinDrake]

Did we come to the conclusion that crosslink committee roots (as well as active validator indices) are not required? Lots of saved hashing.

[vbuterin]

I think so! In which case the right thing to do would be to remove the compact committee logic entirely and move it into the phase 1 spec?

Also, what's the appropriate place to put beacon chain changes in the phase 1 spec that are NOT proof of custody related? (as eg. the persistent committee roots would be)

[JustinDrake]

the right thing to do would be to remove the compact committee logic entirely and move it into the phase 1 spec

I think so. And making light clients clearly fall into phase 1 is a nice conceptual cleanup :)

what's the appropriate place to put beacon chain changes in the phase 1 spec that are NOT proof of custody related?

As suggested by @protolambda here we can have 1_misc-beacon-updates.md complementing 1_custody-game.md. This document would add light client infrastructure, transfers, and make miscellaneous changes like removing assert data.crosslink.data_root == Bytes32().