Modify sync committee logic and parameters to reduce variance

[vbuterin]

Sync committee rewards as currently implemented significantly increase variance in proposer rewards: #2448

For example, if there are 200000 validators (6.4m ETH staked), then during each 1/4-eek (~54 hour) period there is a chance of 512/200000 that a validator will get accepted into the sync committee, so on average that will happen once every 200000/512 * 1/4 = 97.6 eeks, or close to two years. The payout of this "lottery" is 1/8 of that, or ~12.2 eeks (a bit less than four months) of revenue. This is much more severe than block proposing (a chance of 1/200000 per slot, or a lottery worth ~0.38 eeks of revenue once every ~3.05 eeks).

This PR is an alternative to the #2448 author's proposed fix (#2450) and makes three changes to cut make the sync committee lottery less drastic and bring variance closer in line with what is available from block proposing:

• Reduce the SYNC_REWARD_WEIGHT from 8 to 2
• Add a penalty for not participating in the sync committee, so that despite the first change the total net reward for participating vs not participating is only cut down by 2x
• Reduce the sync committee period from 1/4 eek to 1/8 eek (~27 hours)

With these three factors combined, the lottery reduces to ~1.5 eeks of revenue, on average occurring every ~48 eeks. Validators who are maximally unlucky (ie. never become part of a sync committee) only lose ~3.12% of their rewards instead of ~12.5%.

The compromises that this approach makes are:

• In the extreme case where >50% of proposers are operating inefficiently, being in a sync committee becomes a net burden. However, this should be extremely rare, and in such cases validators would likely be suffering inactivity leak penalties anyway.
• Incentive to participate in a sync committee decreased by 2x (but this is IMO an improvement; sync committees are not as important as proposals and deserve to have lower rewards)
• Minimum data syncing needed to maintain a light client increases by 2x (from 24 kB per 54 hours to 24 kB per 27 hours). A burden for on-chain light clients, but still insignificant for others.

[ralexstokes]

In the extreme case where >50% of proposers are operating efficiently,

do you mean inefficiently -- i think the point you are getting at is that sync committee members will not be able to get signatures on-chain if there are many missed slots so that they de facto incur the penalties under this approach

[ralexstokes]

i think this solution makes sense and it is worth reducing rewards variance

we will need to update a few of the tests before merge but they just look like tests that assume no per-slot penalties are possible (and now they would be)

[vbuterin]

do you mean inefficiently -- i think the point you are getting at is that sync committee members will not be able to get signatures on-chain if there are many missed slots so that they de facto incur the penalties under this approach

That was indeed my intention! Fixed.

[djrtwo]

Agree that the variance is a problem and agree that this is a reasonable appraoch

Thank you @potuz for identifying it and thank you @hwwhww and @potuz for updating testing to support this change

We will be discussing this on the call tomorrow before deciding on a merge here: ethereum/eth2.0-pm#220

[potuz]

I may be the only one who thinks so, but after chewing on this for a while I think the approach on #2450 is more fair to everyone. Just leaving a comment before the call

[djrtwo]

@potuz can you expand on "more fair to everyone"?

[potuz]

@potuz can you expand on "more fair to everyone"?

sure, with these parameters the probability of not being included in a committee for two years are 11%, and the rewards that you forfeit are 3%. So this means that at current mainnet parameters we expect at least 15K validators forfeiting 3% of their rewards after two years.

With the approach of #2450 none of this happens since everyone gets their reward up front. And if you fail to participate correctly then the "penalization" you would get would end up in the exact same reward as in the current system. Both the penalty can be increased or lowered by changing the parameter SYNC_PENALTY_WEIGHT in that PR, independently of modifying other weights and maintaining the one base_reward per epoch invariant.

[michaelsproul]

I agree with reducing reward variance, and I'm slightly in favour of this proposal over #2450. I don't see any obstacles to implementing either of them in Lighthouse.

In the original issue @potuz writes:

Without this it would be beneficial for them to move to staking pools

I'm not convinced there's anything we can do by tweaking rewards+penalties to disincentivise centralisation. If there's high reward variance then staking providers have to take this into account in their payouts, but the same applies to high penalty variance (assuming there's a non-zero probability of occasionally missing a sync committee signature and getting penalised). It seems like we're just choosing between a good/bad lottery, with staking pools capable of smoothing out the effects of either. Meanwhile for solo stakers "winning" the lottery is always going to have a greater impact on net profit (greater highs, greater lows). The only situation I can see where the penalty-driven approach could have a decentralising effect is on short time scales, where a small staker can "hop in", and then "hop out" before being selected, while staking providers have to factor in the sync committee risk at all times.

PS: what's an eek?

[potuz]

I'm not convinced there's anything we can do by tweaking rewards+penalties to disincentivise centralisation. If there's high reward variance then staking providers have to take this into account in their payouts, but the same applies to high penalty variance (assuming there's a non-zero probability of occasionally missing a sync committee signature and getting penalised). It seems like we're just choosing between a good/bad lottery, with staking pools capable of smoothing out the effects of either. Meanwhile for solo stakers "winning" the lottery is always going to have a greater impact on net profit (greater highs, greater lows). The only situation I can see where the penalty-driven approach could have a decentralising effect is on short time scales, where a small staker can "hop in", and then "hop out" before being selected, while staking providers have to factor in the sync committee risk at all times.

The point is that the "bad lottery" only affects a presumably tiny subset of 512 validators every 2 days (that is only those that fail to participate in some slots would actually get some penalty, in the form or rewards not being earned). While the rest of the 150K validators will get the full sync committee participation. With a rewards approach, every single validator is on the equivalent of the "bad lottery" until it gets chosen and participates. That is, only a few validators will actually be chosen every two days. The probability of being chosen more than four times in two years with the reduced parameters in this PR are 17,8%, that is, we will be seeing many more validators earning the equivalent to 12% of total earnings, just out of luck of being chosen, vs the 11% than in two years will not earn the 3% of their rewards corresponding to sync committee earnings. So this PR does generate way more variance than #2450, albeit much less than the current specs.

Notice also that in the proposal here, a validator is actually penalized by not participating, not only not earning the sync rewards but getting an active penalty. In the current specs, as well as the proposal of #2450, there is no actual penalty besides not getting the sync reward.

PS: what's an eek?

#1890 (comment)

[michaelsproul]

@potuz Sorry, I'd misunderstood your proposal as involving penalties only. Having thought about it more I think I have a slight preference for your proposal due to the reduced variance (i.e. only for offline sync committee members).

[djrtwo]

merging based on discussions from eth2 call 64