-
Notifications
You must be signed in to change notification settings - Fork 131
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
SIMD-0257: Eliminate vote fees #257
base: main
Are you sure you want to change the base?
SIMD-0257: Eliminate vote fees #257
Conversation
$$c_v = 12 s_v \times 432000 + 4 L \sum_{i\in V} s_i = M$$ | ||
|
||
In order to implement this change, the vote program will track credits $c_v$ as | ||
stake weighted totals. |
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.
could consider also incrementing on vote rather than root to eliminate lockout expiration mods as well but might be too much for this proposal
75edc03
to
86f113b
Compare
86f113b
to
594a2bf
Compare
So a bond wouldn't work for this? |
These validators that are chosen to vote are the top 2000 validators by stake, | ||
rotating every epoch. | ||
|
||
We must abide by the maximum of 18% of the total cluster stake movement allowed | ||
per epoch, | ||
Priority will be given to changes in stake on validators that are already within | ||
the top 2000 validators by stake before adjustments from inactive validators | ||
becoming active or active validators becoming inactive. |
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.
Is it always the case that the heaviest staked 2000 validators get in the next set? I assume that's the case but I want to be sure. It might be useful to add more information on how this affects the leader schedule calculation since those are pre-computed.
Also, I assume that this does create a minimum stake amount to participate in consensus, but it's dynamic and market driven rather than a set amount.
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.
It would be the heaviest, but a rotation into the validator set counts as part of the 9%/9% limit. So if say in an extreme scenario 20% of stake was activating on the 2001st validator and there's already 6% stake activating across the other validators, in order to maintain the cap it might take multiple epochs for this 2001st validator's stake to activate and for it to be recognized as the 2000th validator
what’s stopping me from DOSing the port now? i don’t want to get in, just knock the cluster down |
This allows attackers to spin up numerous minimally staked nodes and spam votes | ||
in an effort to slow down or DoS the cluster. | ||
|
||
In order to address this we choose to limit the number of validators that can vote |
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.
I have mild concerns about this change yielding a massive validator set. There is no mechanism that prevents individuals from spinning up hundreds of negligible stake validators. There should be a minimum required stake.
Thankfully, due to the design of this proposal the minimum value can be kept low. Somewhere between 100-500 SOL.
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 what the validator cap is for.
what happened to the part considering a bond instead of mechanical cap? it was there when i read the rendered version, but done when i switched back to source to comment |
you’re probably going to want to break this into multiple proposals. as is there is too little detail for each component to actually implement it. each independent part should be split out |
What about instead of a hard cap you have it so that voting fees start creeping up if the validator set count goes beyond certain thresholds and decreases over time if it's below certain levels? Voting fees are nice because they help with some sybil issues and help keep crappier validators off of mainnetbeta. I think it could complement this inflation emissions mechanism for validators well https://x.com/7LayerMagik/status/1897772421144264964 |
I'm planning to split out points 2 & 3 "Absolute Vote Credits" and "Vote Inclusion Credits" into a separate proposal. |
@t-nelson vote port should be stake weighted with some low message limits |
I think to keep it simple, the simd should be broken up into a few stages.
|
I think the potential risk to eliminating vote fees and having a validator cap is that there's a bit less resistance to crappier validators and sybils, and if they're higher stake they could prevent better performing but less well capitalized operators (in terms of sol holdings) from joining the network. While this SIMD is being worked on, I think it's worth starting to brainstorm additional ways that we can more strongly disincentivize clutter on mainnet so that the main barrier to entry is performance and good operation rather than capital requirements. We know that inflation rewards and block rewards were never enough incentive for many larger validators to operate well, and improvements in block rewards over the past year only mildly improved the performance of some of the big validators who were poor performers (see binance performance https://stakewiz.com/validator/3N7s9zXMZ4QqvHQR15t5GNHyqc89KduzMP7423eWiD5g). If we trend toward a low REV, low inflation reward situation combined with low voting fees, many of the economic incentives that motivate good validator performance will be weaker. Anyway, I leave it up to @aeyakovenko to think of some creative ways to deal with this. My first inclination is to have a stakeweighted bond type system like Marinade's PSR bond where there is significant loss if there's downtime/poor performance of some sort (not exactly sure if/how skip rate and/or voting could be used for this without issue). Psychologically, people tend to be more averse to losing what they already have vs potential future holdings/rewards, https://en.wikipedia.org/wiki/Endowment_effect, which is why I think this would be more powerful than the current ways to incentivize good performance. There have been reports of sybils spun up in the past year to acquire stakepool stake and these are typically spun up in the same DC/provider. Strong penalties for downtime would increase the potential financial punishment for sybils and increase operational difficulty, helping to disincentivize these as well. |
I think v0, the easiest way to deal with Sybil's is to drop votes outside of the top 2000 stakes. |
No description provided.