cc: @arnetheduck @nisdas @AgeManning @protolambda

This strengthens chain separation such that one must only be concerned about isolating fork version from a different chain when a contentious fork.

One must be concerned about isolating all subsequent fork versions after contentious fork. Do we want to take care about that?

An alternative solution could be as follows:

• set current fork version to genesis_validator_root[:4] in genesis (should be enough to distinguish various networks)
• mix a root of fork version tree into the domain, fork version tree leaf is tuple (epoch, version)

This solution is suitable if we want to take care of domain isolation after contentious fork from the very beginning. Otherwise, it merely makes things more complicated.

Hm, I see isolation from a contentious fork as a much simpler problem than isolation from different chains in general. A contentious fork can just flip a high-order bit and increment versions as normal.

My gut is that your proposed solution might be overly complicated.
Are you suggesting maintaining all (epoch, version) as a list and using the root of the list for domain separation?

One of my goals here is to also minimize changes to the phase 0 consensus while getting relatively good properties

A contentious fork can just flip a high-order bit and increment versions as normal.

Truth. With this alternative we would not need to do an explicit separation. It seems to be the only gain that we get. In general contentious fork will be eager to isolate their fork versions.

My gut is that your proposed solution might be overly complicated.
Are you suggesting maintaining all (epoch, version) as a list and using the root of the list for domain separation?

Agreed, let's keep it simple. Moreover, it's not that clear how to mix a list of fork versions that are likely placed in a config with genesis fork version from the state.

This looks good to me!