Skip to content
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

Draft
wants to merge 6 commits into
base: main
Choose a base branch
from

Conversation

AshwinSekar
Copy link
Contributor

No description provided.

@AshwinSekar AshwinSekar changed the title Eliminate vote fees SIMD-0257: Eliminate vote fees Mar 6, 2025
$$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.
Copy link
Contributor Author

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

@AshwinSekar AshwinSekar force-pushed the eliminate-vote-fees branch from 75edc03 to 86f113b Compare March 6, 2025 22:00
@AshwinSekar AshwinSekar force-pushed the eliminate-vote-fees branch from 86f113b to 594a2bf Compare March 6, 2025 22:01
@DataKnox
Copy link

DataKnox commented Mar 6, 2025

2 ways to prevent vote spam

So a bond wouldn't work for this?

Comment on lines +209 to +216
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.
Copy link
Contributor

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.

Copy link
Contributor Author

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

@t-nelson
Copy link
Contributor

t-nelson commented Mar 6, 2025

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

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.

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.

@t-nelson
Copy link
Contributor

t-nelson commented Mar 6, 2025

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

@t-nelson
Copy link
Contributor

t-nelson commented Mar 6, 2025

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

@7layermagik
Copy link

7layermagik commented Mar 6, 2025

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

@AshwinSekar
Copy link
Contributor Author

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

I'm planning to split out points 2 & 3 "Absolute Vote Credits" and "Vote Inclusion Credits" into a separate proposal.
I have implementation details to share that is too much to fit here, and I think these points are valuable even without removing the vote fees.

@aeyakovenko
Copy link

@t-nelson vote port should be stake weighted with some low message limits

@aeyakovenko
Copy link

aeyakovenko commented Mar 9, 2025

@AshwinSekar @MaxResnick

I think to keep it simple, the simd should be broken up into a few stages.

  1. Reducing vote fees proportional to block increases. 60m blocks imply 25% lower vote fees if block byte limits are tracked correctly. Leaders by default drop votes for validators outside the top 2000. So this is a soft limit.

  2. The rest can be handled in pieces. Dedicating space to votes, selecting the quorum, and actually landing the vote decrease once all that's done.

@7layermagik
Copy link

7layermagik commented Mar 9, 2025

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.

@aeyakovenko
Copy link

@7layermagik

I think v0, the easiest way to deal with Sybil's is to drop votes outside of the top 2000 stakes.

# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

8 participants