Align fork epoch with the start of EPOCHS_PER_SYNC_COMMITTEE_PERIOD

[hwwhww]

Issue

• Suggestion: align fork epoch with the start of EPOCHS_PER_SYNC_COMMITTEE_PERIOD.
• Pros:
  1. More stable network at the starting epochs of the fork.
  2. Aesthetically align the time setup.
• Cons: It would be more difficult to coordinate the suitable clock time.

If we do it, I'd like to add an invariant check to the pyspec builder. Therefore we have to adjust the temporary stub ALTAIR_FORK_EPOCH to the number that matches the assertion.

Proposal

1. Update the TBD *_FORK_EPOCH stub to 2**63.
2. Add ALTAIR_FORK_EPOCH % EPOCHS_PER_SYNC_COMMITTEE_PERIOD == 0 checks to pyspec builder.

[ralexstokes]

the merge and sharding constants have to change as they are downstream of the altair fork so they need to have the alignment condition as well?

[hwwhww]

That was only for simple alignment. Open to discussion! :)

[ralexstokes]

i'm not opposed to this change but would say its more of a broader coordination issue across everyone who will be executing the fork -- the downside is that it constrains the timing of the fork (and raises the question how we want to handle future forks...) so that if e.g. we want to execute the fork at a given slot (bc the wall clock time is convenient for some reason) we may have to wait up to do ~48 hrs extra

may be worth raising on the implementers call thursday to get input from more sources before merging this

[protolambda]

Is the alignment of the stubs (which are not supposed to be used) really necessary? I think we can just add a special case for the stub value in the invariant check.

For non-stub values, I brought up the alignment issue during review in March here: #2201 (comment) A shorter period at the start seems fine to me if the test cannot avoid it. And yes, for mainnet we can align it nicely.

And I would prefer an unit test that checks alignment of all mainnet fork version values, to keep the spec builder simple.

[hwwhww]

@ralexstokes

its more of a broader coordination issue across everyone who will be executing the fork

Agreed!

This alignment is half for aesthetic improvement and half for technical improvement. It would look bad if we somehow set ALTAIR_FORK_EPOCH + 1 the period boundary, so I think some stability improvement is better than none.

[hwwhww]

@protolambda

I would prefer an unit test that checks alignment of all mainnet fork version values, to keep the spec builder simple.

Fair enough! I was thinking about putting invariant checks in the markdown file, but that was too messy. Moving to unit test should be good.

[hwwhww]

Thanks for @ajsutton, @arnetheduck, @djrtwo, and @dankrad 's feedback on the call:

1. Restrict sync committee period calculation boundaries #2406 ensures that the first two epochs have the same sync committee.
2. In Teku's prototyping, a short period is not a big problem.
3. Considering coordination overhead likely not worth it.

Other time period parameters:

• EPOCHS_PER_HISTORICAL_VECTOR: ~0.8 years
• SLOTS_PER_HISTORICAL_ROOT: ~27 hours
  ... are also too long to align with.

Leaving this PR open for a few days in case we get new feedback. If no, I'll close this issue. :)

edited: HISTORICAL_ROOTS_LIMIT SLOTS_PER_HISTORICAL_ROOT

[arnetheduck]

During the meeting, I think the HISTORICAL_ROOTS_LIMIT was mentioned to constrain the alignment to a month (8k epochs) which indeed is very long.

I think1 day is fairly palatable however - should the proposal for #2417 be accepted, this alignment would help make the transition a lot easier.

[arnetheduck]

Oops, wrong link, should be #2428

[djrtwo]

closing for now, as discussed two calls ago this does not buy us too much on simplification