Avoid finalization when zero total stake

[Nashatyrev]

Problem

After applying some number of 'empty slot transitions' to any state all validators are finally exited due to inactivity penalties and the state has zero active validators. From this point the state becomes finalized due to the >= condition (see proposed change).
Of course this is not the case for the actual network but may cause client software issues. E.g. when the client is not synced yet but is trying calculate the state of the current slot (based on system clocks) by applying 'empty slot transitions'. When encountering a finalized epoch it may stick to this zero-balance fork and then just fail to sync correctly

Solution

Change >= to > condition to avoid justifying epoch when the total stake balance is zero

[JustinDrake]

Side note: That the tests are still passing suggests we're missing an edge-case test for those thresholds.

[djrtwo]

I'm a bit conflicted on this one. All validators exiting the chain is a failure scenario beyond the balance being equal to zero. The chain cannot even be built at this point.

Mathematically, the threshold for finality should be >= so I'm not certain I'm willing compromise that to handle the case where a chain that can no longer be built will prevent finalizing itself.

@JustinDrake The reason this scenario is not tested is that there is no longer a chain to test here.

[JustinDrake]

All validators exiting the chain is a failure scenario beyond the balance being equal to zero.

I don't think that's the necessarily the case. The effective balances can be zero without all the validators having exited.

handle the case where a chain that can no longer be built

I think the point is that there are scenarios where the effective balances are all zero and the chain can still be built. (Remember that effective balance is rounded down to the closest EFFECTIVE_BALANCE_INCREMENT, and that there is an exit queue.)

[djrtwo]

Still thinking through such a scenario. In such a case, the remaining zero-balance validators are on a death march unless new capital is deposited into the system, right?

EDIT: -- actually won't they be ejected far before their effective gets to zero in the inactivity leak scenario?

If we need to handle this case, I would prefer the following blocker statement rather than compromise the mathematical integrity finality conditional statements.

if get_total_active_balance(state) == 0:
    return

[Nashatyrev]

My two cents: from my perspective >= and > are almost equivalent for non-zero balance especially taking into account that 2/3 is kind of conceptual ratio.
Adding another couple of ifs looks less intrusive but makes the spec a bit more heavy
Either way I will be pretty fine with any solution

[djrtwo]

I'm pretty sure I'm going to go with the extra if. Taking care of it now with a test on the case.

[JustinDrake]

I'm pretty sure I'm going to go with the extra if.

It turns out there are other problems with rounding down the balance, namely divisions by zero in a couple places. I would want to avoid putting if statements everywhere. Maybe we can round the balance up instead?

[djrtwo]

Closing in favor of #1123