-
Notifications
You must be signed in to change notification settings - Fork 4.4k
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
Add staking rewards design proposal for delegation #3148
Add staking rewards design proposal for delegation #3148
Conversation
This needs a rebase/rewrite that acknowledges the current design that we merged earlier this week. |
fixup! new proposal
fixup! review comments
91b1859
to
f1ed938
Compare
@garious, rebased |
fixup! s/network/cluster
@aeyakovenko, this proposal needs more work. It starts off with a first sentence that doesn't make any sense. The second sentence has a spelling error. The terminology is confusing because it doesn't acknowledge the terminology in the existing architecture (which there's already an implementation of). It'd be especially helpful to acknowledge the existing definition of "delegate" and note that there's currently a I think you could take a very different approach here, which is simply to move |
@garious why would the authorized_voter be part of the StakeState? |
fixup!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Getting closer. To me, the big innovation here is the claimed_credits
field that's set to VoteState::credits
when the staker chooses a voter.
### RewardsInstruction::Initialize | ||
|
||
* `account[0]` - Out Param - The RewardsState instance. | ||
`RewardsState::claimed_credits` is initialized to `VoteState::credits`. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is the clever bit, but why do it in . Initialize and not as a separate instruction? Why can't the staker change its VoteSigner?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That can be implemented. It doesn’t add any expressive power to the program over creating a new instance for every new stake.
We might need that instruction if there is a warmup and cool down period for creating stakes.
Can you add |
Looks like our designs pretty much converged. Anything else you want to grab from https://github.com/solana-labs/solana/pull/3212/files so I can close it? |
…olana-labs#3148) The arguments to specify full and incremental snapshot archives paths used to be a global argument; these were moved to only be instantiated on commands that needed them in solana-labs#1773. But, when the arguments were moved from app-level to subcommand-level, the code that matches the arguments was not updated to look at subcommand-matches instead of app-matches.
…tory (backport of solana-labs#3148) (solana-labs#3153) ledger-tool: Fix create-snapshot default value for output_directory (solana-labs#3148) The arguments to specify full and incremental snapshot archives paths used to be a global argument; these were moved to only be instantiated on commands that needed them in solana-labs#1773. But, when the arguments were moved from app-level to subcommand-level, the code that matches the arguments was not updated to look at subcommand-matches instead of app-matches. (cherry picked from commit 1d9947c) Co-authored-by: steviez <steven@anza.xyz>
Problem
Current staking architecture requires a validator vote per delegated stake. It has two main problems
Summary of Changes
Cover the current architecture and its problems and propose an alternative that allows for passive delegation and a single vote for many delegated stakes.
Fixes #
tag: @garious (I'll add you as the last reviewer)