Eth2.0-specs: Put per-slot processing after per-epoch processing

[JustinDrake]

At least two advantages:

1) The section "State root processing" can be merged in with "Per-slot processing"
2) The automatic ejection logic if the balance is too low can happen as one of the last steps.

[djrtwo]

I'll work through the details on this and make sure we aren't missing anything important.

When the block signature was an attestation that had to be included in the next block, we needed to allow old attestations into the current block to ensure this was possible and based this on last_state_transition_recalc. None of this is true anymore, but I'll make sure there are no more little things like this and do the PR if so.

[djrtwo]

It's not as clean as we'd prefer. You need to do some per-slot processing prior to the epoch-transition no matter what.

Such as the following:

• update state.slot
• update state.latest_block_hashes

We could do something like the following:

• per-slot pre-processing (update slot, latest_block_hashes, etc)
• per-epoch processing
• per-slot processing

This isn't much cleaner and has the downside that even though you have a new block available, you aren't opportunistically including the new attestations in the epoch finality calculations.

Seems like there are some trade-offs either way and I'm not yet convinced that switching it is cleaner/optimal.

happy to discuss here :)

[mkalinin]

As I can see from the spec, current epoch transition is processed during transition from latest slot of _current_ epoch to the first slot of the _next_ epoch. In case when committees update takes place as a part of epoch transition the block which this update is linked to becomes eventually invalid. As a result there is an ambiguity in validity of slot committees. Hence, block with slots slot % EPOCH_LENGTH == 0 could be superseded after the import by block proposed by new committee. This ambiguity can have other potential drawbacks.

Even if above assumption is not true (maybe I am missing something), IMO, it's reasonable to process epoch transition right at the end of the epoch. Which is at the end of slot % (EPOCH_LENGTH - 1) == 0 slots transition according to current spec. Btw, it would be helpful to specify epoch boundaries explicitly.

[vbuterin]

Even if above assumption is not true (maybe I am missing something), IMO, it's reasonable to process epoch transition right at the end of the epoch. Which is at the end of slot % (EPOCH_LENGTH - 1) == 0 slots transition according to current spec. Btw, it would be helpful to specify epoch boundaries explicitly.

This seems reasonable to me!

[djrtwo]

Yeah, I am more convinced that doing per-slot/epoch before per-block gives the client more optionality in local processing.

• If it is an epoch transition, they can do the large epoch recalc then try to process the block locally. If the block has a bad state root, they can just discard the block processing steps and keep the epoch recalc around.
• If they receive a block at the slot at the end of the epoch ((slot+1) % EPOCH_LENGTH == 0), they can start the per-epoch slot transition even without receiving the next block. When they do receive a block for slot % EPOCH_LENGTH == 0 or beyond, the block processing is tacked onto the complex epoch processing already completed.

[vbuterin]

If they receive a block at the slot at the end of the epoch ((slot+1) % EPOCH_LENGTH == 0), they can start the per-epoch slot transition even without receiving the next block. When they do receive a block for slot % EPOCH_LENGTH == 0 or beyond, the block processing is tacked onto the complex epoch processing already completed.

Why the complexity? Why not just move the epoch processing to the end of the last slot of each epoch, and keep the structure the same?

[djrtwo]

oh yeah...

That might actually fix #352...

[djrtwo]

closed via #492