Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Sync committee rewards occur with very low frequency. #2448

Closed
potuz opened this issue May 26, 2021 · 1 comment
Closed

Sync committee rewards occur with very low frequency. #2448

potuz opened this issue May 26, 2021 · 1 comment
Labels
Altair aka HF1

Comments

@potuz
Copy link
Contributor

potuz commented May 26, 2021

In the current Altair Specs, only SYNC_COMMITTEE_SIZE (512) validators out of the current 150K on mainnet will earn rewards for over 2 days. Validators that aren't chosen to participate on the sync committee will forfeit 1/8 of their earnings until they are finally chosen. The probabilities of not being in a single sync committee for a single validator are

1 month             |          95.65% 
6 months            |          76.33%
1 year              |          57.86%
2 years             |          33.37%

Which means that after two years of staking, we will still see at least 50K validators without earning 1/8 of their rewards.

A proposal to remedy this is to simply get rid of the committee sync rewards, and apply a penalty to those validators that fail to participate in the committee. The total rewards can be guaranteed to be still one base_rewards by adjusting the weights as


TIMELY_SOURCE_WEIGHT	uint64(14)
TIMELY_TARGET_WEIGHT	uint64(28)
TIMELY_HEAD_WEIGHT	uint64(14)
PROPOSER_WEIGHT	        uint64(8)
WEIGHT_DENOMINATOR	uint64(64)

And adding a penalty weight

SYNC_PENALTY_WEIGHT	uint64(8)

The changes to the current specs seem to be minimal, a WIP can be found in

https://github.com/ethereum/eth2.0-specs/compare/dev...potuz:penalize-sync-comiittee?expand=1

Some dissadvantages of the minimal proposal above are

  • Validators on the first sync committe may be penalized unfairly for the first few slots
  • Validators that are offline and are assigned to a sync committee will be severely penalized

The first point can be fixed in-protocol by not penalizing on the first few epochs. The second one, under current conditions of participation rate above 99%, the probability than an offline validator is chosen for a sync committee is 3 * 10^-5 so it is negligible.

Advantages are

  • Single stakers will be able to maintain their full rewards without the need of luck. Without this it would be beneficial for them to move to staking pools
  • The penalty can be simply reduced by adjusting two parameters without modifing the invariant of one base_reward earnings per epoch.
@potuz potuz mentioned this issue May 27, 2021
Closed
vbuterin added a commit that referenced this issue May 27, 2021
@vbuterin
Modify sync committee logic and parameters to reduce variance
a89ecce 
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 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 efficiently, 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.
@vbuterin vbuterin mentioned this issue May 27, 2021
Merged
@hwwhww hwwhww added the Altair aka HF1 label Jun 1, 2021
@djrtwo
Copy link
Contributor

djrtwo commented Jun 7, 2021

addressed in #2453

@djrtwo djrtwo closed this as completed Jun 7, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
Altair aka HF1
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@djrtwo @hwwhww @potuz