Eth2.0-specs: Eth1 voting when block_hash is junk

[paulhauner]

As discussed with @JustinDrake and @djrtwo, the honest validator guide requires that for a proposer to cast an Eth1Data vote, they must resolve state.eth1_data.block_hash to a block number.

It is not specified how to proceed if state.eth1_data.block_hash is junk (e.g. there's a dishonest majority or super-crazy-extreme eth1 re-org).

Suggestions

1. As suggested by @JustinDrake simply cast a random vote. This breaks the eth1 linking (and therefore deposits), favoring liveness over safety. An extra-protocol fix will be required.
2. Set previous_eth1_distance to some constant (4096?) and try to salvage eth1 linking.
3. Fail block production, halting the entire chain.

I prefer (1), primarily because it tends towards "failing loudly" instead of trying to recover a broken system (which may introduce weird scenarios, like a decreasing deposit count).

[JustinDrake]

favoring liveness over safety

Do you mean favouring satefy over liveness, i.e. Eth1 linking can stall but never produces a bad Eth1 link?

[vbuterin]

I think the idea is that it favors the safety _and_ liveness of the beacon chain over liveness of the eth1->eth2 deposit mechanism. Which feels like a good tradeoff to make.

[djrtwo]

This is likely to halt the chain even if we take approach (1).

In a scenario in which an attacker manages to get bad eth1data.root into the state, they could just as easily get in a bad eth1data.deposit_count and if this number is greater than state.eth1_deposit_index, then no blocks will be able to be produced due to the requirement that deposits _must_ be included on chain if there are any unprocessed.

I suppose the other attack might be to make eth1data.deposit_count == state.eth1_deposit_index, in this case, the chain would remain live and no further deposits could be made.

[paulhauner]

This can be closed as it is resolved with the new eth1 voting scheme :)