Inactivity penalty for participating validators might be too high

[djrtwo]

Issue

During an inactivity leak it is expected that those validators that are participating optimally would see their balance unchanged whereas, those that are participating but not optimally will lose a small amount, and those that are failing to vote on the "correct" target are subject to a quadratic leak.

It turns out that due to some of the details of the calculations performed in get_attestation_deltas that an optimally participating validator would still lose some amount of capital. This is due to two minor details in the way rewards are applied

1. Micro-incentives for FFG source, target, and head are scaled by attesting_balance // total_balance
2. max_attester_reward for inclusion delay is less than base_reward due to the portion given to the proposer

These two sources of reward are less than base_reward even for an optimally participating validator during an inactivity leak. (1) is certainly scaled below the maximum for target and head because the chain is not finalizing and thus the attesting_balance < 2/3 * total_balance. (2) is always scaled slightly below the maximum regardless of the inclusion time due to a portion going to the proposer.

During an inactivity leak, all active validators receive a BASE_REWARDS_PER_EPOCH * base_reward penalty with the expectation that an optimally performing validator's rewards will be perfectly balanced out by this penalty resulting in a net 0 affect on balance. As discussed above, the max reward for an optimally performing validator is less than BASE_REWARDS_PER_EPOCH * base_reward, thus they will lose capital.

Proposed solution

We could be more nuanced about the penalty applied here to ensure a penalty balancing scaled by the proper amounts, but that seems a bit messy.

Still thinking on it.

[vbuterin]

There's reasons for other broader changes to how incentives work; namely, having a global per-epoch penalty that rewards cancel out instead of having separate inactivity penalties (it simplifies the logic, and also it moves us closer to #1340).

If we do that, that would be a good opportunity to also adjust to make sure we fix this.

[djrtwo]

@vbuterin Any thoughts on this and the related issue?

[GregTheGreek]

Can we bump this? It seems there has been a lot of confusion after the topaz network had an outage.

[prestonvanloon]

I'm also interested in this. We often see user confusion around losses during any gap of finality larger than 5 epochs. It doesn't make sense to users that they were online, performed 100% of their duties in a timely manner, and still realized a negative change in their validator balance.

[djrtwo]

addressed in #1830!
Thanks for the nudge on this one. Will make for a cleaner validation experience