Rounded effective balance #862
Conversation
Use the rounded balance for the effective balance to homogenise the on-onchain finality and crosslink gadgets with the fork choice rule and the light client logic. Minor cleanups: * Use `increase_balance` and `decrease_balance` in `apply_rewards` instead of `set_balance`. * Use `get_effective_balance` for activations and ejections. * Rename `high_balance` to `rounded_balance` (we no longer have `high_balance` and `low_balance`).
| @@ -1091,7 +1088,7 @@ def get_effective_balance(state: BeaconState, index: ValidatorIndex) -> Gwei: | |||
| """ | |||
| Return the effective balance (also known as "balance at stake") for a validator with the given ``index``. | |||
| """ | |||
| return min(get_balance(state, index), MAX_DEPOSIT_AMOUNT) | |||
| return min(state.validator_registry[index].rounded_balance, MAX_DEPOSIT_AMOUNT) | |||
There was a problem hiding this comment.
This function is used for reward/penalty calculations. Do we want to use rounded balance for reward/penalties?
There was a problem hiding this comment.
I'd argue so. The balance at stake is rounded so rewards/penalties should also be. Basically I'd argue use rounded everywhere for consensus stuff.
There was a problem hiding this comment.
This does effect a validator's effective rate of return as rounded_balance <= actual_balance. In the event that a validator has >= 32ETH and has always had so, then this doesn't matter. In the event that a validator's balance drops to 16ETH, however, by this makes the difference between having 64 ETH and 65 ETH after validating for a long time.
If we allow balances to grow exponentially as per #730, then this always matters. See graphs attached below:
There was a problem hiding this comment.
Right. I guess a downside of using rounded balance for rewards is that it creates a misalignment between capital costs (not rounded) and rewards (rounded).
|
Close in favour of #949 |
Use the rounded balance for the effective balance to homogenise the on-onchain finality and crosslink gadgets with the fork choice rule and the light client logic.
Minor cleanups:
increase_balanceanddecrease_balanceinapply_rewardsinstead ofset_balance.get_effective_balancefor activations and ejections.high_balancetorounded_balance(we no longer havehigh_balanceandlow_balance).