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.

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

Deleting and recreating vote account causes calculate_stake_points_and_credits to exit early #22512

Closed
CriesofCarrots opened this issue Jan 14, 2022 · 13 comments · Fixed by #22546
Assignees

Comments

@CriesofCarrots
Copy link
Contributor

Problem

If an active vote account with any previous epoch's of voting history is emptied of lamports and then recreated at the same address, the vote account and delegated stake accounts will stop seeing staking rewards generated due to this case in the stake program evaluating as true:

if new_vote_state.credits() <= stake.credits_observed {

This is because the recreated vote account starts from scratch with 0 credits, while the stake account remembers all the credits from the original account. The calculate_stake_points_and_credits early exit will continue until the observed credits in the recreated vote account surpasses the account's original observed credits, or until the stake account resets its observed credits by deactivating and redelegating to the vote account.

Proposed Solution

When this case is first hit (on the first epoch boundary after vote-account recreation), reset the stake-account's observed credits to 0 (and activation epoch to current epoch?) so that next epoch, the stake account starts seeing new credits.

@mvines
Copy link
Member

mvines commented Feb 3, 2022

Wouldn’t #2265 also essentially fix this issue?

@CriesofCarrots
Copy link
Contributor Author

@mvines typo in that link? (2265 seems irrelevant)

@mvines
Copy link
Member

mvines commented Feb 3, 2022

Ugh! Smol screen copy/paste missed the last digit. Need a check digit for PR numbers in addition to SOL addresses!

#22651 is the one

@CriesofCarrots
Copy link
Contributor Author

Ah, got it. #22651 does help safeguard against this issue, but doesn't completely prevent it. That change just makes the withdrawal to 0 harder for the validator to do, and gives more warning to the stake delegators to deactivate before they could potentially end up in this state.

To wit, if a vote account that stops voting for one full epoch, then withdraws to 0 and is recreated at the same address: Any stake accounts that aren't deactivated during the period of non-voting will end up in the same state as described in the issue and will not produce rewards until the vote accounts new credits reach whatever level the vote account was at before it stopped voting. We can decide not to care about stake accounts in this state, but it still seems incorrect from a stake-history perspective.

@mvines
Copy link
Member

mvines commented Feb 3, 2022

Thanks, I see now.

The PR to fix just makes me nervous as it's touching quite sensitive parts of the runtime and this issue seems like an edge case that probably doesn't really matter practically. ⚖️

Was this just something that was observed in the code originally or did somebody stumble over it?

@CriesofCarrots
Copy link
Contributor Author

The latter, there are stake accounts in this state in the wild. Not a lot, but some: #22546 (comment)

@mvines
Copy link
Member

mvines commented Feb 3, 2022

Interesting! I guess we could go another way and simply make vote accounts unclose-able too :)

@CriesofCarrots
Copy link
Contributor Author

Interesting! I guess we could go another way and simply make vote accounts unclose-able too :)

Hmm, that is an option! But wouldn't help the stake accounts currently in this state either.

@mvines
Copy link
Member

mvines commented Feb 3, 2022

But wouldn't help the stake accounts currently in this state either.

Yes, true. I guess I'd be ok with leaving that as is. The situation is unfortunate for them but they could have already easily take action by simply noticing that they've been earning nothing and moved their stake elsewhere in anger. This is still their best recourse for however many future epochs elapse between now and when we can ship and activate the fix on mainnet.

@refi93
Copy link

refi93 commented Feb 21, 2023

@CriesofCarrots Just wondering - what does happen with the rewards that have not been awarded to the vote/stake accounts affected by this bug? Are they completely ignored, or are they distributed among the delegations created later on? Or perhaps something else?

@CriesofCarrots
Copy link
Contributor Author

what does happen with the rewards that have not been awarded to the vote/stake accounts affected by this bug?

@refi93 , those rewards are completely ignored, and credits will start accruing anew at that epoch boundary. This is because the vote account state is completely lost on defunding, so there is no way to tell what the missing credits or rewards should have been.

@refi93
Copy link

refi93 commented Feb 23, 2023

Thanks! One more thing that isn't clear to me about the bug:

The calculate_stake_points_and_credits early exit will continue until the observed credits in the recreated vote account surpasses the account's original observed credits

"observed credits" refers to credits for the current epoch or to all credits ever observed since vote account (or delegation) creation? I'm trying to understand what does it take for the rewards to start accruing for a delegation made before a vote account key reset

@CriesofCarrots
Copy link
Contributor Author

"observed credits" refers to credits for the current epoch or to all credits ever observed since vote account (or delegation) creation?

"Observed credits" refers to all credits observed since vote account creation.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants