major clients should:
define deterministic future address of the eth2.0 validator deposit migration address.
coredev to announce intention to release future hard fork update, with fork-choice condition="existence of code at eth2.0 migration contract address"
consider now, the definition of eth1.x is everything that will be in the hard fork at the release date of eth2.0
does this accelerate the eth1.x release schedule? Does this make ProgPoW, StateRent+BiggerBlockGasLimit or eWASM, more attractive to fast-track?