SIMD-0249: Delay Commission Updates #249
Conversation
jstarry
changed the title
|
This to me is a conceptual no brainer. |
|
Agreed. No brainer. |
|
|
||
| NA | ||
|
|
||
| ## Detailed Design |
There was a problem hiding this comment.
is this going to be updated to include implementation details? this section is supposed to be sufficiently descriptive that someone can implement the feature/change from this document alone
jstarry
force-pushed
the
delay-commission-updates
branch
from
0a911c0 to
0965d97
Compare
jstarry
changed the title
jstarry
changed the title
joncinque
left a comment
joncinque
left a comment
There was a problem hiding this comment.
Looks great to me! Just a couple of questions
| available in-protocol. The only exception is inflation reward distribution for | ||
| epoch `E == 0`. In that case, use the commission rate set by vote accounts in | ||
| the genesis config. |
There was a problem hiding this comment.
How exactly does this work for new validators?
If I create a vote account and start getting delegations in epoch E - 1, then those stakes aren't active until the start of epoch E, and they should receive rewards after epoch E.
Is the idea to use the commission as of the vote account's creation during E - 1 when calculating payouts at the end of epoch E?
There was a problem hiding this comment.
If I create a vote account and start getting delegations in epoch
E - 1, then those stakes aren't active until the start of epochE, and they should receive rewards after epochE.
Actually at earliest they will start receiving rewards for epoch E + 1 (distributed in epoch E + 2) because that's the earliest epoch in which your vote account could be in the leader schedule. We use the stake distribution at the beginning of epoch E to determine the leader schedule for E + 1 and epoch E is the earliest epoch in which your vote account would be staked.
There was a problem hiding this comment.
I updated this section and explicitly called out the new validator case: 1175904
There was a problem hiding this comment.
Oh gotcha, I wasn't aware that it took an extra epoch to start earning voting rewards. I thought as soon as a validator had active stake, they could earn voting rewards. Thanks for the clarification!
There was a problem hiding this comment.
Sorry I was mixing up inflation rewards with block revenue. My explanation about the leader schedule makes no sense for inflation rewards. So yes, we need to handle new validators as you pointed out!
It looks like it's also possible to delegate to a vote account that isn't fully initialized yet. So when a vote account is initialized and starts voting in epoch E it would already be earning rewards in that epoch.
Since there are a few edge cases here that add complexity to the proposal I think it's best to simplify this SIMD to only being about commission rates being updated to basis points and then try to handle commission rugs in a separate SIMD.
There was a problem hiding this comment.
I moved the commission rate in basis points change to a new SIMD and reverted this SIMD back to dealing with delayed commission rate updates. New SIMD is here: #291
| - Validators will be able to set inflation rewards commission rates in basis | ||
| points. |
There was a problem hiding this comment.
This presupposes that VoteStateV4 already exists, correct? If so, can you add a reference to that SIMD?
There was a problem hiding this comment.
I added a "Dependencies" section in 1175904
jstarry
changed the title
jstarry
force-pushed
the
delay-commission-updates
branch
from
a25eca4 to
1ef0635
Compare
jstarry
changed the title
joncinque
left a comment
joncinque
left a comment
There was a problem hiding this comment.
Short, sweet, and clear, looks good to me!
7 participants
Context: solana-labs/solana#29346