Explicitly specify state advancement in p2p spec

[terencechain]

While implementing Altair's p2p spec into code, we realized that Prysm does not advance beacon state up to the particular slot when the object is referencing that slot.

For example, when an Altair block's parent state on phase 0, the node would use that parent state (phase0) to verify the signature, and the signature verification would failed due to fork version miss match. Correct behavior would have been advancing parent state (phase0) up to block's slot then use processed state (altair) to verify block signature.

Just wanted to share this lesson learned after seeing 3 missed blocks post fork boundary in the devnet this morning. Whether we should explicitly define state advancement in the p2p spec is up for debate and I wonder if anyone has an opinion on this

[djrtwo]

Curious -- what slot does the p2p reference state sit at?

[terencechain]

Curious -- what slot does the p2p reference state sit at?

We were using the parent state to verify block signature. In the failure case, parent state slot would be < ALTAIR_FORK_SLOT and the block slot would be >= ALTAIR_FORK_SLOT

[ralexstokes]

in the interest of reducing verbosity in the spec, i'd suggest leaning towards the current style used in the networking specs which implies the state object (rather than say the state transition spec where it is arguably more valuable to be super explicit) -- there is obviously a trade-off here b/t how much the spec spells out and how much content there is to maintain/digest when working w/ client implementations.

would love to hear any other implementer's feedback and happy to make a pass on clarifying anything that has broad support amongst client teams :)