search

solana-labs / solana

Web-Scale Blockchain for fast, secure, scalable, decentralized apps and marketplaces.
https://solanalabs.com
Apache License 2.0
13.17k stars 4.29k forks source link

Raise stake minimum delegation #22559

Open brooksprumo opened 2 years ago

brooksprumo commented 2 years ago

Problem

Stake accounts have a very low minimum delegation requirement (just 1 lamport, on top of being rent exempt). This may cause the number of stake accounts to be higher than necessary, which affects both #20384 and #21604.

Proposed Solution

Raise the minimum delegation for stake accounts. Right now the minimum delegation is 1 lamport. I feel the minimum delegation should be much higher (i.e. >= 1 SOL).

Details

Minimum Balance and Rent

Currently, stake accounts must be rent exempt. At the moment, this amount cannot be staked, so an additional 1 lamport is required for new accounts. For the sake of this proposal, the rent exempt reserve concept shall not be changed, just the additional balance. This means that the minimum delegation is currently 1 lamport, and I'm proposing increasing that to 1 SOL.

Creating Accounts

No changes needed.

Delegating

The minimum delegation amount will increase from 1 lamport. A new error StakeError::InsufficientDelegation will indicate if the requested delegation amount is below the minimum.

Split/Withdraw

Stake accounts' balance shall stay at-or-above the minimum balance, similar to creating stake accounts. With the one exception of withdrawing all lamports/closing the account.

If the stake account is already delegated, then both the source and destination accounts must retain a delegation amount at least the minimum delegation.

Querying the Minimum Delegation Amount

As to not change the stake account's data structure, new functions/instructions will be added to query the minimum delegation for stake accounts.

Governance/Voting

Voting/approving this proposal will use the feature proposal program to handle the governance.

Related

Other Protocols

Ethereum

Eth 2 requires 32 ETH to stake to be a validator. Smaller amounts of eth can be staked in stake pools. link

Avalanche

The minimum amount required to stake to a delegator is 25 AVAX (not counting pools), and 2000 AVAX to be a validator. link

Polkadot

From what I can tell, nominating has a minimum of 80 DOT (about to be 120 DOT), which I believe is like staking to a delegator. link

Fantom

Staking on Fantom has a 1 FTM minimum. link

Tasks

Features

joncinque commented 2 years ago

A few comments on this proposal:

TODO: How should/can transfers be handled? Should the minimum balance still be enforced here? How does this interact with staked vs non-staked balances?

You can only move lamports out of a stake account with a withdraw or split instruction on the stake program, so we can definitely enforce it, no problems there. There's already a lot of logic to make sure it never goes under rent-exemption, so we'd just have to bump out that number.

brooksprumo commented 2 years ago

I ran some queries using the postgres accounts db plugin:

number of stake accounts:  506,580
number of stake pool accounts: 607

size of stake account:       200 bytes
size of stake pool account: 4008 bytes

stake account rent exempt minimum:      0.00228288 sol
stake pool account rent exempt minimum: 0.02878656 sol

number of stake accounts at minimum balance:   188
number of stake accounts <       0.01 sol:  65,723
number of stake accounts <       0.1  sol:  97,993
number of stake accounts <       1    sol: 151,536
number of stake accounts <      10    sol: 288,877
number of stake accounts <     100    sol: 401,489
number of stake accounts <   1,000    sol: 499,528
number of stake accounts <  10,000    sol: 502,783
number of stake accounts < 100,000    sol: 505,391

So stake accounts already have a minimum balance requirement of 0.0022 sol, which is greater than the 0.001 minimum for stake pools, thus superseding that minimum, yes?

@joncinque If 1 sol is too high, what about bumping the minimum to 0.1 sol?

cc @jstarry @carllin

joncinque commented 2 years ago

So stake accounts already have a minimum balance requirement of 0.0022 sol, which is greater than the 0.001 minimum for stake pools, thus superseding that minimum, yes?

Sorry, I should have been clearer on this. The 0.001 minimum for stake accounts in stake pools is on top of the rent-exemption, so it would be more like ~0.00328288 SOL.

A minimum of 0.1 SOL will still be pretty tough for stake pools that want to include 1k validators, but maybe that's fine, and they'll just take longer to add of all those stakes. And then for rebalancing, they'll have to be sure to respect that minimum. I'm not a huge fan of the solution, but if 20% fewer stake accounts makes a difference, it'll have to be done, right?

Funny story, right before seeing this issue, I coincidentally created a stake with 0.01 SOL :grimacing:

brooksprumo commented 2 years ago

The 0.001 minimum for stake accounts in stake pools is on top of the rent-exemption, so it would be more like ~0.00328288 SOL.

Oh gotcha! Yes, I missed this earlier.

A minimum of 0.1 SOL will still be pretty tough for stake pools that want to include 1k validators, but maybe that's fine, and they'll just take longer to add of all those stakes.

Is it beneficial for a pool to spread a very small amount of SOL across a lot of validators? I'm not sure if that's better than delegating to a smaller number of validators with more SOL each, right? Esp if the goal is to increase decentralization and increase the superminority. Then, as you said, add more validators over time. Even 1 SOL seems quite reasonable to me still.

And then for rebalancing, they'll have to be sure to respect that minimum.

Yah.

I'm not a huge fan of the solution, but if 20% fewer stake accounts makes a difference, it'll have to be done, right?

I don't think the number of stake accounts is the concern, but rather the ability to create lots of new accounts cheaply. Which ties back to #21348 and #21604.

jstarry commented 2 years ago

A few comments on this proposal:

* A minimum of 1 SOL will make stake pools very difficult to bootstrap.  We got a lot of negative feedback from potential stake pool managers when the program forced a minimum of 1 SOL

@joncinque can you elaborate on what's so difficult about bootstrapping pools with this change? It seems like you're suggesting pools should be allowed to create many small stake accounts which I think is a bad thing. They are "pools" which means they pool together assets so why wouldn't the pool be able to meet the same threshold of X SOL that every individual has to reach?

jstarry commented 2 years ago

@joncinque how much stake per validator do the top pools delegate currently?

jstarry commented 2 years ago

I would like to see us push up >= 10 SOL minimum, 1 SOL is still too low of a barrier to create many stake accounts

joncinque commented 2 years ago

I don't think the number of stake accounts is the concern, but rather the ability to create lots of new accounts cheaply.

If that's the case, then shouldn't rent be increased? With millions of token accounts, and 500k stake accounts, seems like that would better serve the issue all at once.

can you elaborate on what's so difficult about bootstrapping pools with this change? It seems like you're suggesting pools should be allowed to create many small stake accounts which I think is a bad thing. They are "pools" which means they pool together assets so why wouldn't the pool be able to meet the same threshold of X SOL that every individual has to reach?

We have to change up the design for adding / removing validators. Currently, the manager fronts that amount and gets nothing in return, which is fine for small amounts. We'll make it come from the reserve instead.

We were thinking about making the stake pool program non-upgradeable, so it would be best to get this change in sooner to update the program. Or maybe we punt it to v2.

how much stake per validator do the top pools delegate currently?

It's quite a range, especially for Marinade. Looks like most stake pools would be ok even with a 10 SOL minimum. Note that https://solanacompass.com/stake-pools is pretty fun to poke around!

The current foundation pool is only doing 1-3 SOL per validator, but that's because most of the funds are still in the old system.

It's too bad to force people with small amounts of SOL to go through a stake pool with the smart contract / manager risk, but liveness of the chain is certainly more important.

brooksprumo commented 2 years ago

I don't think the number of stake accounts is the concern, but rather the ability to create lots of new accounts cheaply.

If that's the case, then shouldn't rent be increased? With millions of token accounts, and 500k stake accounts, seems like that would better serve the issue all at once.

Yes, I agree. However, increasing rent is harder than increasing the minimum stake. See the discussion in #21348 for more information.

It's too bad to force people with small amounts of SOL to go through a stake pool with the smart contract / manager risk, but liveness of the chain is certainly more important.

Agreed.

t-nelson commented 2 years ago

I don't think the number of stake accounts is the concern

The absolute number of stake accounts is definitely a concern

brooksprumo commented 2 years ago

Would this need a governance vote too? If yes, how does that process work?

t-nelson commented 2 years ago

Would this need a governance vote too? If yes, how does that process work?

Yeah definitely. We haven't done a real one. The closest thing was enabling inflation, which was basically unanimous

jstarry commented 2 years ago

Would this need a governance vote too? If yes, how does that process work?

Probably with this: https://spl.solana.com/feature-proposal

Instead of a core contributor holding the private key for a feature activation, we can use a PDA from the feature proposal program.

ruuda commented 2 years ago

I'm proposing increasing that to 1 SOL I would like to see us push up >= 10 SOL minimum

You are proposing that people who have less than $1,400 (at the time of writing) don’t get to stake directly — they don’t get to make an independent choice of what validator they stake with? That sounds like it would be bad for censorship-resistance to me.

Of course it would be good for stake pools — indeed the high barrier to direct staking is one of the reasons that Lido is successful on Ethereum — but I think it’s important that users can make an independent choice if they want to.

t-nelson commented 2 years ago

Probably with this: https://spl.solana.com/feature-proposal

Instead of a core contributor holding the private key for a feature activation, we can use a PDA from the feature proposal program.

IMO there should be some governance process before engineering resources are dedicated to the effort

t-nelson commented 2 years ago

You are proposing that people who have less than $1,400 (at the time of writing) don’t get to stake directly — they don’t get to make an independent choice of what validator they stake with? That sounds like it would be bad for censorship-resistance to me.

Of course it would be good for stake pools — indeed the high barrier to direct staking is one of the reasons that Lido is successful on Ethereum — but I think it’s important that users can make an independent choice if they want to.

Any limit can be reduced as code is improved to safely support more stake accounts

jstarry commented 2 years ago

Probably with this: https://spl.solana.com/feature-proposal Instead of a core contributor holding the private key for a feature activation, we can use a PDA from the feature proposal program.

IMO there should be some governance process before engineering resources are dedicated to the effort

Why? I think we can dedicate eng resources as needed for features to improve the scalability of the protocol. If it doesn't get accepted we revise and try again. We do need some form of this in the short / medium term until we lazily compute stake rewards

brooksprumo commented 2 years ago

Should the MINIMUM_STAKE_DELEGATION constant be a Sysvar? Would there be value to that? Would other programs want to be able to query that? Would governance changes be easier if it were a Sysvar?

brooksprumo commented 2 years ago

For the governance vote, my understanding is that since this basically is to activate a feature, whatever change is voted on needs to be within code that is feature-aware. Specifically, a constant would not work. Is that right?

The minimum stake delegation is currently a constant here: https://github.com/solana-labs/solana/blob/bb9f9c8dd51073477a57707580e2befe1eed8866/sdk/program/src/stake/mod.rs#L12

In order to have a governance vote to change this value, what would be the right/best way to do enable that?

Or is it possible to have a governance vote, and then change the constant after the fact? (I'm assuming 'no', but want to verify.)

mvines commented 2 years ago

Or is it possible to have a governance vote, and then change the constant after the fact? (I'm assuming 'no', but want to verify.)

It's certainly possible but that's not great. The stake program can check whether the feature is enabled itself actually, the bank doesn't need to tell it. Such a feature could be enabled by the workflow that the feature-proposal program provides

brooksprumo commented 2 years ago

I was talking with @joncinque yesterday about Sysvar stuffs, to try and figure out if that's the best way forward. One pro is that stake pools can query the Sysvar and proactively update their apps to support raising the minimum stake delegation. However, I don't understand all the interactions that Sysvars have with the rest of the system, esp the history/gotchas, so he recommended I get input from @mvines @t-nelson @jackcmay. Wdyt about the Sysvar route?

mvines commented 2 years ago

A sysvar would be useful for programs (like stake pool programs) so they can read the current minimum balance from the cluster instead of hard coding it

t-nelson commented 2 years ago

sysvar sgtm. i'd suggest that we avoid some of the pains of the past and think forward. assume we'll extend it in the future, so wrap it in a versioned StakeProgramConfig struct.

jackcmay commented 2 years ago

Sysvar make sense, and one that is not supported by account passing, just .get()

brooksprumo commented 2 years ago

assume we'll extend it in the future, so wrap it in a versioned StakeProgramConfig struct.

@t-nelson Is there an existing versioned struct somewhere already that I can look at/use as reference?

brooksprumo commented 2 years ago

and one that is not supported by account passing, just .get()

@jackcmay Does that mean not implementing Sysvar?

t-nelson commented 2 years ago

@t-nelson Is there an existing versioned struct somewhere already that I can look at/use as reference?

Nonce and vote accounts are both versioned https://github.com/solana-labs/solana/blob/ae76fe2bd74ab0b7ef579486f8034380ccdc7df2/sdk/program/src/nonce/state/mod.rs https://github.com/solana-labs/solana/blob/ae76fe2bd74ab0b7ef579486f8034380ccdc7df2/programs/vote/src/vote_state/vote_state_versions.rs

jackcmay commented 2 years ago

and one that is not supported by account passing, just .get()

@jackcmay Does that mean not implementing Sysvar?

Yeah, I would implement get via impl_sysvar_get and not the Sysvar trait. This would be the first to do it so you might run into funnyness.

brooksprumo commented 2 years ago

Yeah, I would implement get via impl_sysvar_get and not the Sysvar trait. This would be the first to do it so you might run into funnyness.

Yeah... there's lots of places that assume the sysvars implement Sysvar, not just get here. What's the downside to implementing the Sysvar trait?

brooksprumo commented 2 years ago

Ok! I've gone a deep way into the rabbit hole of Sysvars. I've put up a PR with my work so far. As you can see, it touches a lot of stuff, and it's not complete (the PR calls out the known remaining work). It's also likely that the PR can be split up into smaller PRs.

Ultimately, the work on this PR has made me want to check in and ask is this worth it?

Adding the sysvar is a means-to-an-end: enabling a governance vote to rase the minimum delegation amount. The sysvar, in general, would also be nice to have for programs to query, but it's not desperately needed at the moment. And going down the sysvar-route, implementing it not as an account is new and also not strictly necessary.

I'm wondering where to drawn the line on the amount of work/feature creep for this.

How valuable—is it really—to raise the minimum delegation amount? How valuable is a true governance vote w.r.t. handling the raise? How valuable is a new-style sysvar (one that's not in an account)?

Hoping to get some guidance on this. Thanks in advance! @jstarry @joncinque @mvines @jackcmay @t-nelson

ruuda commented 2 years ago

How valuable—is it really—to raise the minimum delegation amount?

As far as I understand from the original comment, it’s a hack to try to reduce the accounts data size, but stake accounts are only a tiny fraction of the accounts, and adding a minimum delegation amount has severe downsides, so to me it does not seem worth changing.

jstarry commented 2 years ago

I know you're already taken the sysvar approach but what about making use of the new return value feature instead to get the minimum value? The stake program could have a get_minimum_delegation instruction which returns the value. I prefer this approach because it requires less work than setting up a new syscall to get the sysvar value.

How valuable—is it really—to raise the minimum delegation amount?

It's valuable because it gives validators a way to limit the amount of epoch boundary calculations they need to do to deliver rewards to stakers (https://github.com/solana-labs/solana/issues/20384). I'm less worried about the account data size because rent fee adjustments can be made if account data gets too large. We just don't have any knobs to turn if the number of stake delegations grows large at the moment.

How valuable is a true governance vote w.r.t. handling the raise?

Valuable because it's up to the network to decide how staking economics change. Why do you bring this up? Implementation can make use of the feature proposal program as you've already outlined in the issue tasks.

How valuable is a new-style sysvar (one that's not in an account)?

In my opinion, not too valuable. I'd prefer we move quicker to add the ability for the cluster to counteract excessive stake delegations without blocking on new runtime functionality like account-less sysvars.

brooksprumo commented 2 years ago

I know you're already taken the sysvar approach but what about making use of the new return value feature instead to get the minimum value? The stake program could have a get_minimum_delegation instruction which returns the value. I prefer this approach because it requires less work than setting up a new syscall to get the sysvar value.

Love it! Yes, this sounds like a better approach. I'll switch over to this.

It's valuable because it gives validators a way to limit the amount of epoch boundary calculations they need to do to deliver rewards to stakers (#20384).

Great! I was wondering if this was also an issue, so good to know.

How valuable is a true governance vote w.r.t. handling the raise?

Valuable because it's up to the network to decide how staking economics change. Why do you bring this up?

This was to explore how direct the vote needed to be. On one side is the sysvar, where the vote would feature gate an update to the sysvar's state, and therefor the value for the minimum stake delegation. On the other side is a vote that does not touch a sysvar and instead the minimum stake delegation constant is updated after the fact. I am not endorsing this approach; rather I wanted to make sure I understood the spectrum of options.

I'd prefer we move quicker to add the ability for the cluster to counteract excessive stake delegations without blocking on new runtime functionality like account-less sysvars.

💯

brooksprumo commented 2 years ago

I ran some queries using the postgres accounts db plugin:

number of stake accounts:  506,580
number of stake pool accounts: 607

size of stake account:       200 bytes
size of stake pool account: 4008 bytes

stake account rent exempt minimum:      0.00228288 sol
stake pool account rent exempt minimum: 0.02878656 sol

number of stake accounts at minimum balance:   188
number of stake accounts <       0.01 sol:  65,723
number of stake accounts <       0.1  sol:  97,993
number of stake accounts <       1    sol: 151,536
number of stake accounts <      10    sol: 288,877
number of stake accounts <     100    sol: 401,489
number of stake accounts <   1,000    sol: 499,528
number of stake accounts <  10,000    sol: 502,783
number of stake accounts < 100,000    sol: 505,391

Running some queries with Geyser:

solana=> SELECT COUNT(*) FROM account WHERE owner = E'\\x06a1d8179137542a983437bdfe2a7ab2557f535c8a78722b68a49dc000000000' AND lamports < 1000000000;
count | 537899

solana=> SELECT COUNT(*) FROM account WHERE owner = E'\\x06a1d8179137542a983437bdfe2a7ab2557f535c8a78722b68a49dc000000000';
count | 587209

Number of stake accounts with lamports < 1 SOL = 537,899 Number of all stake accounts: 587,209 Percentage of stake accounts with lamports < 1 SOL is about 91.6%

bji commented 2 years ago

Sorry the CLI isn't very clear on this in its help text -- if a split-stake operation is done, does it have to be to a new stake account? Or can it be into a stake account in the same state (active/not active) and delegation (either both not delegated, or both delegated to the same validator)?

If it must be a new stake account, then a minimum of 1 SOL in a stake account would mean that it's not possible to split-stake off less than 1 SOL. I think this would be a big issue, because users who want to profit-take on their own schedule would be unable to do so.

brooksprumo commented 2 years ago

Sorry the CLI isn't very clear on this in its help text -- if a split-stake operation is done, does it have to be to a new stake account?

The destination of a split instruction must be StakeState::Uninitialized: https://github.com/solana-labs/solana/blob/348fe9ebe2656da5ce76998d29edcd2a2bf2d7bc/programs/stake/src/stake_state.rs#L665-L667

If it must be a new stake account, then a minimum of 1 SOL in a stake account would mean that it's not possible to split-stake off less than 1 SOL.

As per my answer in the feature-gate issue: https://github.com/solana-labs/solana/issues/24357#issuecomment-1168713918

For non-delegated accounts, this is possible. For delegated accounts, there was a discussion on Discord on how to handle this case. Here's a link to the end of that discussion: https://discord.com/channels/428295358100013066/885976714646290473/989592022904098816

michaelh-laine commented 2 years ago

I ran some queries using the postgres accounts db plugin:

number of stake accounts:  506,580
number of stake pool accounts: 607

size of stake account:       200 bytes
size of stake pool account: 4008 bytes

stake account rent exempt minimum:      0.00228288 sol
stake pool account rent exempt minimum: 0.02878656 sol

number of stake accounts at minimum balance:   188
number of stake accounts <       0.01 sol:  65,723
number of stake accounts <       0.1  sol:  97,993
number of stake accounts <       1    sol: 151,536
number of stake accounts <      10    sol: 288,877
number of stake accounts <     100    sol: 401,489
number of stake accounts <   1,000    sol: 499,528
number of stake accounts <  10,000    sol: 502,783
number of stake accounts < 100,000    sol: 505,391

Running some queries with Geyser:

solana=> SELECT COUNT(*) FROM account WHERE owner = E'\\x06a1d8179137542a983437bdfe2a7ab2557f535c8a78722b68a49dc000000000' AND lamports < 1000000000;
count | 537899

solana=> SELECT COUNT(*) FROM account WHERE owner = E'\\x06a1d8179137542a983437bdfe2a7ab2557f535c8a78722b68a49dc000000000';
count | 587209

Number of stake accounts with lamports < 1 SOL = 537,899 Number of all stake accounts: 587,209 Percentage of stake accounts with lamports < 1 SOL is about 91.6%

Your numbers don't add up. Your data shows 151k below 1 SOL, not sure how you then get 537k.

From my own analysis today of all accounts owned by the Stake Program there are now 587k total stake accounts of which 185k have a balance below 1 SOL and 225k have an active stake below 1 SOL. That's in the 30% range.

michaelh-laine commented 2 years ago

From my data

total stake accounts are 587,000

Setting a stake delegation of 0.1 SOL or even 0.01 SOL would also achieve a significant reduction with less of a burden on small users and be more future compatible for changes in the SOL price affecting people's ability to create accounts meeting the min delegation.

1 SOL is arbitrary, as are all numbers, but sub-1 SOL accounts account for 38.3% of stakes, while sub 0.1 SOL accounts account for 23.5% of stakes, while being a 10x reduction in min delegation amount.

At the same time the underlying issue of rewards computation shouldn't depend on us having to continuously artificially reduce the number of stake accounts somehow.

My vote is for 0.1 SOL = 100m lamports.

(Edited to add more data:

Everstake has 51k stakes with active stake <1 SOL, might be worth reaching out to Exodus about how they prompt users on stake creation.

Chorus and and stake.systems have 45k accounts between them which have an average active stake of < 0.05 SOL in aggregate. For Chorus the avg stake of these accounts is incredibly low at 0.029 SOL.

The top 4 validators by delegated stakes <1 SOL account for 113,500 stake accounts, or over 50% of all stakes below 1 SOL.

Top 50 validators sorted by no of accounts delegated with active stake < 1 SOL attached.

image

All numbers are on active (delegated) stake, and exclude rent exempt reserve and deactivated stake accounts.

For anyone wishing to parse the data themselves, solana stakes mostly times out due to inefficient encoding, this gPA call returns in ~15 seconds all accounts with parsed data:

curl https://ssc-dao.genesysgo.net/ -X POST -H "Content-Type: application/json" -d '{"jsonrpc":"2.0", "id":1, "method":"getProgramAccounts", "params":["Stake11111111111111111111111111111111111111",{"encoding":"jsonParsed"}]}';

/end more data)

brooksprumo commented 2 years ago

I ran some queries using the postgres accounts db plugin:

number of stake accounts:  506,580
number of stake pool accounts: 607

size of stake account:       200 bytes
size of stake pool account: 4008 bytes

stake account rent exempt minimum:      0.00228288 sol
stake pool account rent exempt minimum: 0.02878656 sol

number of stake accounts at minimum balance:   188
number of stake accounts <       0.01 sol:  65,723
number of stake accounts <       0.1  sol:  97,993
number of stake accounts <       1    sol: 151,536
number of stake accounts <      10    sol: 288,877
number of stake accounts <     100    sol: 401,489
number of stake accounts <   1,000    sol: 499,528
number of stake accounts <  10,000    sol: 502,783
number of stake accounts < 100,000    sol: 505,391

Running some queries with Geyser:

solana=> SELECT COUNT(*) FROM account WHERE owner = E'\\x06a1d8179137542a983437bdfe2a7ab2557f535c8a78722b68a49dc000000000' AND lamports < 1000000000;
count | 537899

solana=> SELECT COUNT(*) FROM account WHERE owner = E'\\x06a1d8179137542a983437bdfe2a7ab2557f535c8a78722b68a49dc000000000';
count | 587209

Number of stake accounts with lamports < 1 SOL = 537,899 Number of all stake accounts: 587,209 Percentage of stake accounts with lamports < 1 SOL is about 91.6%

Your numbers don't add up. Your data shows 151k below 1 SOL, not sure how you then get 537k.

Thanks for double checking these numbers. Yes, the first set of data showed 151k accounts with a balance below 1 SOL. The second query returned a count of 537k accounts with a balance below 1 SOL. I'll need to investigate why the second query returned such a different value.

jnwng commented 2 years ago

a question that came up from a wallet team regarding what happens to existing stake accounts that are below the minimum stake threshold, recording here for posterity:

from @brooksprumo:

All existing stake accounts are grandfathered in. No accounts will change, there will be new checks in the instructions, which would prevent new delegations of < 1 SOL