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.
could consider also incrementing on vote rather than root to eliminate lockout expiration mods as well but might be too much for this proposal
AshwinSekar
force-pushed
the
eliminate-vote-fees
branch
from
75edc03 to
86f113b
Compare
AshwinSekar
force-pushed
the
eliminate-vote-fees
branch
from
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.
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.
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
There was a problem hiding this comment.
It seems to me that you are creating completely unnecessary complexity here.
Or a full example is needed where using a conditional 2000 validators from the same set that was used to calculate slot leaders for this epoch would be unsafe.
|
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.
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.
This is what the validator cap is for.
There was a problem hiding this comment.
Spammers will just keep enough low-staked validators to keep the quota permanently occupied just to make it impossible for new validators to vote. High-staked players can thus ensure that no new validators ever join the voting set, if they so choose.
|
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. |
|
|
||
| ## Proofs that the proposed system satisfies the desiderata: | ||
|
|
||
| It's clear that maximum validator set size satisfies properties 6 and 7 by |
There was a problem hiding this comment.
"It's clear" is bad pattern. If it’s “clear,” there’s no point in writing about it. If it’s being written, then it’s not entirely clear.
There was a problem hiding this comment.
Every step in a proof is obvious once you understand it, it is still standard to reference obvious things.
|
|
||
| It's clear that maximum validator set size satisfies properties 6 and 7 by | ||
| definition. And that capping entry and exit to 18% satisfies 5, also by | ||
| definition. 1. is satisfied by the removal of vote costs and is the point of the |
There was a problem hiding this comment.
When someone writes “by definition,” I want to look up the definition and make sure it’s actually there. In this case, there isn’t even a clear definition. I can guess what you mean, but I don’t want to.
| in the next block. Each leader $i$ has reward function. | ||
|
|
||
| $$ R_i(s_1,\dots,s_n,c_1,\dots,c_n, u_1,\dots,u_n) = I s_i \frac{c_i}{M} + Iu_i - | ||
| [\sum_{j=1}^n I s_j \frac{c_j}{M} + u_i]\cdot \frac{s_i}{T} $$ |
There was a problem hiding this comment.
In the last term, you are adding Sols and u_i (which is either a fraction or credits, not entirely clear). But in any case, this does not make sense.
|
In any case, I would like to see everything in whole numbers. It makes no sense to calculate all fractions in the process. Let the leader receive exactly the same number of credits as the validator; all conversions can be done later. It might also make sense to simplify things and just remove the grace period from TVS. At the end, when distributing inflation, I would like to see not some hypothetical maximums in the denominators but simple sums of credits accumulated over the epoch. It also seems questionable to use staked weight because slot distribution has noise in this distribution. Thus, something like this: my_efficiency = where leader_part + vote_part = 1 my_inflation_sol = (my_efficiency / total_efficiency) * inflation_sol |
| block, they will have their own CU limit. | ||
|
|
||
| 5. To address denial of service attacks via votes, the cluster will only process | ||
| votes from 2000 active validators. These validators will be the top 2000 |
There was a problem hiding this comment.
An idea - instead of hard limit can we cap the growth rate of the allowed validator set at a rate of 2% per epoch? This would allow new staked validators to gradually join without imposing a hardcoded limit.
|
I'm pretty against capping the validator set and I don't think it has the effects that SIMD advocates say it will. Setting an arbitrary hard cap not based on metrics makes it impossible for someone to participate with a loss-leader validator. I would also mention we only have ~1300 validators at the moment so setting a preemptive cap of 2000 feels unnecessary at this time. I would strongly recommend this proposal is broken out into a separate SIMD as it is not directly related to reducing vote costs |
| 4. Vote transactions will no longer count towards the global CU limit in the | ||
| block, they will have their own CU limit. | ||
|
|
||
| 5. To address denial of service attacks via votes, the cluster will only process |
There was a problem hiding this comment.
Ideas:
-
Stake-Based Voting Limits – Validators with more stake get more voting slots, preventing low-stake validators from spamming the network.
-
Smart Vote Processing – Prioritize votes from reliable validators. If the network is congested, drop votes from frequently failing validators.
-
Vote Bundling – Compress multiple votes into one packet to reduce network load and improve efficiency.
-
Spam Prevention Fees – Introduce small fees for excessive voting during congestion, discouraging spam.
-
Group Voting with Cryptography – Use cryptographic techniques to combine multiple validator votes into one, reducing transaction volume.
There was a problem hiding this comment.
- Limit minimal stake for voting at some non-zero number like 100 SOL. It is low enough such that anyone who wants can realistically afford to have that much stake, yet high enough such that a meaningful amount of spam voters becomes really expensive to keep running.
It is impossible to remove vote costs without some other way to restrict the size of the validator set from growing too large. Yes the active validator set is <1300 today, because vote costs exist and are high. If vote costs were eliminated then the cost to bring down the network via validator/vote spam would be negligible if the optics of a capped validator set are really that bad then we should not do this proposal at all and let the vote fees continue to implicitly cap the size of the validator set.
I don't understand this argument. The minimum stake required to run a validator will be set at the 2000th highest staked validator under this proposal. The cost to run a loss leader validator would then be the cost of stake rental (e.g. marinade) to get above that threshold. The cost of this would likely be lower than the current vote cost. |
that is not a resource free strategy. aliyun IPs are cheaper |
Vote spam is possible today, one can choose to burn sol just to create a bunch of staked identities and submit vote transactions. Sure it is not "free" but no attack truly is. What we need to confirm a block is a certain % of the stake supporting it. This means we do not need to include all votes into the block. So if low-staked validators choose to submit votes and it turns out we do not need them for consensus then we can just not include them in the block. Cost of packets is near zero anyway. |
| block, they will have their own CU limit. | ||
|
|
||
| 5. To address denial of service attacks via votes, the cluster will only process | ||
| votes from 2000 active validators. These validators will be the top 2000 |
There was a problem hiding this comment.
This will essentially limit number of validators on the cluster to 2000. Without supporting low staked validators it will be hard to onboard new validator providers because they will find it very hard to get this amount of stake.
This does not guarantee that a high staked validator will not DDOS vote transactions to the cluster. So it seems that you are assuming DDOS can only come from low staked validator which IMO is wrong.
No description provided.