blockworks-foundation
/
solana-with-rpc-optimizations
mirror of https://github.com/blockworks-foundation/solana-with-rpc-optimizations.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Update stake-delegation-and-rewards.md

This commit is contained in:
Josh Kauffman 2020-07-27 22:14:21 -04:00 committed by Michael Vines
parent 24831ea42d
commit 239080c131
1 changed files with 25 additions and 27 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

52
docs/src/cluster/stake-delegation-and-rewards.md
View File

@ -2,7 +2,7 @@
title: Stake Delegation and Rewards
---
Stakers are rewarded for helping to validate the ledger. They do this by delegating their stake to validator nodes. Those validators do the legwork of replaying the ledger and send votes to a per-node vote account to which stakers can delegate their stakes. The rest of the cluster uses those stake-weighted votes to select a block when forks arise. Both the validator and staker need some economic incentive to play their part. The validator needs to be compensated for its hardware and the staker needs to be compensated for the risk of getting its stake slashed. The economics are covered in [staking rewards](../implemented-proposals/staking-rewards.md). This section, on the other hand, describes the underlying mechanics of its implementation.
Stakers are rewarded for helping to validate the ledger. They do this by delegating their stake to validator nodes. Those validators do the legwork of replaying the ledger and sending votes to a per-node vote account to which stakers can delegate their stakes. The rest of the cluster uses those stake-weighted votes to select a block when forks arise. Both the validator and staker need some economic incentive to play their part. The validator needs to be compensated for its hardware and the staker needs to be compensated for the risk of getting its stake slashed. The economics are covered in [staking rewards](../implemented-proposals/staking-rewards.md). This section, on the other hand, describes the underlying mechanics of its implementation.
## Basic Design
@ -25,34 +25,33 @@ The rewards process is split into two on-chain programs. The Vote program solves
VoteState is the current state of all the votes the validator has submitted to the network. VoteState contains the following state information:
- `votes` - The submitted votes data structure.
- `credits` - The total number of rewards this vote program has generated over its lifetime.
- `credits` - The total number of rewards this Vote program has generated over its lifetime.
- `root_slot` - The last slot to reach the full lockout commitment necessary for rewards.
- `commission` - The commission taken by this VoteState for any rewards claimed by staker's Stake accounts. This is the percentage ceiling of the reward.
- Account::lamports - The accumulated lamports from the commission. These do not count as stakes.
- `authorized_voter` - Only this identity is authorized to submit votes. This field can only modified by this identity.
- `node_pubkey` - The Solana node that votes in this account.
- `authorized_withdrawer` - the identity of the entity in charge of the lamports of this account, separate from the account's address and the authorized vote signer
- `authorized_withdrawer` - the identity of the entity in charge of the lamports of this account, separate from the account's address and the authorized vote signer.
### VoteInstruction::Initialize\(VoteInit\)
- `account[0]` - RW - The VoteState
- `account[0]` - RW - The VoteState.
`VoteInit` carries the new vote account's `node_pubkey`, `authorized_voter`, `authorized_withdrawer`, and `commission`
`VoteInit` carries the new vote account's `node_pubkey`, `authorized_voter`, `authorized_withdrawer`, and `commission`.
other VoteState members defaulted
other VoteState members defaulted.
### VoteInstruction::Authorize\(Pubkey, VoteAuthorize\)
Updates the account with a new authorized voter or withdrawer, according to the VoteAuthorize parameter \(`Voter` or `Withdrawer`\). The transaction must be signed by the Vote account's current `authorized_voter` or `authorized_withdrawer`.
- `account[0]` - RW - The VoteState
`VoteState::authorized_voter` or `authorized_withdrawer` is set to to `Pubkey`.
- `account[0]` - RW - The VoteState.
`VoteState::authorized_voter` or `authorized_withdrawer` is set to `Pubkey`.
### VoteInstruction::Vote\(Vote\)
- `account[0]` - RW - The VoteState
`VoteState::lockouts` and `VoteState::credits` are updated according to voting lockout rules see [Tower BFT](../implemented-proposals/tower-bft.md)
- `account[0]` - RW - The VoteState.
`VoteState::lockouts` and `VoteState::credits` are updated according to voting lockout rules see [Tower BFT](../implemented-proposals/tower-bft.md).
- `account[1]` - RO - `sysvar::slot_hashes` A list of some N most recent slots and their hashes for the vote to be verified against.
- `account[2]` - RO - `sysvar::clock` The current network time, expressed in slots, epochs.
@ -65,18 +64,17 @@ A StakeState takes one of four forms, StakeState::Uninitialized, StakeState::Ini
StakeState::Stake is the current delegation preference of the **staker** and contains the following state information:
- Account::lamports - The lamports available for staking.
- `stake` - the staked amount \(subject to warm up and cool down\) for generating rewards, always less than or equal to Account::lamports
- `stake` - the staked amount \(subject to warmup and cooldown\) for generating rewards, always less than or equal to Account::lamports.
- `voter_pubkey` - The pubkey of the VoteState instance the lamports are delegated to.
- `credits_observed` - The total credits claimed over the lifetime of the program.
- `activated` - the epoch at which this stake was activated/delegated. The full stake will be counted after warm up.
- `deactivated` - the epoch at which this stake was de-activated, some cool down epochs are required before the account is fully deactivated, and the stake available for withdrawal
- `authorized_staker` - the pubkey of the entity that must sign delegation, activation, and deactivation transactions
- `authorized_withdrawer` - the identity of the entity in charge of the lamports of this account, separate from the account's address, and the authorized staker
- `activated` - the epoch at which this stake was activated/delegated. The full stake will be counted after warmup.
- `deactivated` - the epoch at which this stake was de-activated, some cooldown epochs are required before the account is fully deactivated, and the stake available for withdrawal.
- `authorized_staker` - the pubkey of the entity that must sign delegation, activation, and deactivation transactions.
- `authorized_withdrawer` - the identity of the entity in charge of the lamports of this account, separate from the account's address, and the authorized staker.
### StakeState::RewardsPool
To avoid a single network wide lock or contention in redemption, 256 RewardsPools are part of genesis under pre-determined keys, each with std::u64::MAX credits to be able to satisfy redemptions according to point value.
To avoid a single network-wide lock or contention in redemption, 256 RewardsPools are part of genesis under pre-determined keys, each with std::u64::MAX credits to be able to satisfy redemptions according to point value.
The Stakes and the RewardsPool are accounts that are owned by the same `Stake` program.
@ -86,27 +84,27 @@ The Stake account is moved from Initialized to StakeState::Stake form, or from a
- `account[0]` - RW - The StakeState::Stake instance. `StakeState::Stake::credits_observed` is initialized to `VoteState::credits`, `StakeState::Stake::voter_pubkey` is initialized to `account[1]`. If this is the initial delegation of stake, `StakeState::Stake::stake` is initialized to the account's balance in lamports, `StakeState::Stake::activated` is initialized to the current Bank epoch, and `StakeState::Stake::deactivated` is initialized to std::u64::MAX
- `account[1]` - R - The VoteState instance.
- `account[2]` - R - sysvar::clock account, carries information about current Bank epoch
- `account[3]` - R - sysvar::stakehistory account, carries information about stake history
- `account[4]` - R - stake::Config account, carries warmup, cooldown, and slashing configuration
- `account[2]` - R - sysvar::clock account, carries information about current Bank epoch.
- `account[3]` - R - sysvar::stakehistory account, carries information about stake history.
- `account[4]` - R - stake::Config account, carries warmup, cooldown, and slashing configuration.
### StakeInstruction::Authorize\(Pubkey, StakeAuthorize\)
Updates the account with a new authorized staker or withdrawer, according to the StakeAuthorize parameter \(`Staker` or `Withdrawer`\). The transaction must be by signed by the Stakee account's current `authorized_staker` or `authorized_withdrawer`. Any stake lock-up must have expired, or the lock-up custodian must also sign the transaction.
- `account[0]` - RW - The StakeState
- `account[0]` - RW - The StakeState.
`StakeState::authorized_staker` or `authorized_withdrawer` is set to to `Pubkey`.
### StakeInstruction::Deactivate
A staker may wish to withdraw from the network. To do so he must first deactivate his stake, and wait for cool down.
A staker may wish to withdraw from the network. To do so he must first deactivate his stake, and wait for cooldown.
The transaction must be signed by the stake's `authorized_staker`.
- `account[0]` - RW - The StakeState::Stake instance that is deactivating.
- `account[1]` - R - sysvar::clock account from the Bank that carries current epoch
- `account[1]` - R - sysvar::clock account from the Bank that carries current epoch.
StakeState::Stake::deactivated is set to the current epoch + cool down. The account's stake will ramp down to zero by that epoch, and Account::lamports will be available for withdrawal.
StakeState::Stake::deactivated is set to the current epoch + cooldown. The account's stake will ramp down to zero by that epoch, and Account::lamports will be available for withdrawal.
### StakeInstruction::Withdraw\(u64\)
@ -115,7 +113,7 @@ Lamports build up over time in a Stake account and any excess over activated sta
- `account[0]` - RW - The StakeState::Stake from which to withdraw.
- `account[1]` - RW - Account that should be credited with the withdrawn lamports.
- `account[2]` - R - sysvar::clock account from the Bank that carries current epoch, to calculate stake.
- `account[3]` - R - sysvar::stake_history account from the Bank that carries stake warmup/cooldown history
- `account[3]` - R - sysvar::stake_history account from the Bank that carries stake warmup/cooldown history.
## Benefits of the design
@ -154,7 +152,7 @@ Stakers who have delegated to that validator earn points in proportion to their
### Stake warmup, cooldown, withdrawal
Stakes, once delegated, do not become effective immediately. They must first pass through a warm up period. During this period some portion of the stake is considered "effective", the rest is considered "activating". Changes occur on epoch boundaries.
Stakes, once delegated, do not become effective immediately. They must first pass through a warmup period. During this period some portion of the stake is considered "effective", the rest is considered "activating". Changes occur on epoch boundaries.
The stake program limits the rate of change to total network stake, reflected in the stake program's `config::warmup_rate` \(set to 25% per epoch in the current implementation\).