-
Notifications
You must be signed in to change notification settings - Fork 3.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Any validator can lower other validators reward at no cost #2525
Comments
This isn't totally true though is it? you can get kicked for liviness slashing if you lower it too much? I guess maybe a validator could try to keep it just above that ratio. I guess the solution might be to have another layer of "continuous" liveliness slashing (could be bulked together), but only in proportion to how much a proposer loses by not including your vote - Therefor it's in the best interest of both the proposer and the other validators to both submit whenever it's possible to do so . ^ it's a nice win-win mechanism I think.. thoughts? |
Sure, but assume the validator your attacking has
This is a cool idea! I'm not sure validators would like this micro-slashing idea. (It just feels bad from a social perspective to me) windowing / epoching the slashes would alleviate the computational burden, plus I am in general in favor of occasionally slower blocks. I do think switching to a fee distribution model where we can only reward the validators who sign a block is preferrable, and then reworking equations to disincentivize exclusion of others signatures. FTR, we had a discussion between me, Jae, Jack, and Chris in Berkeley. We ended on Jae suggesting the similar continuous slashing / microslashing model, and also the possibility of fixing the equations in the model where we reward each validator who signs a given block. (No decision at all, just discussion) The ideas were centered around how detectable we think this is, can we tweak parameters to mitigate applicability, and how impactful will it be in practice. I think we can safely punt this concern to soon-after-launch, though I think validators will do it, and it will be hard to detect. I'm interested to see if it happens on GoS |
agreed - good to hear! - yeah I think microslashing on an epoch basis could make sense - I think we rename it from "slashing" to "not-getting the bonus" we may find more support ;) hehhe |
Vitalik wrote up a whole paper on this class of attacks. |
In the current model a validator gets a fee reward regardless of whether they signed that block or not. However the proposers block reward is proportional to the amount of staking signing the block. Thus a validator can just withhold
x%
of their signatures to lower the relative reward of other block proposers, with no loss of profit to themselves. This allows them to drive up their proportion of stake. Worse, this enables a targeted attack, which will likely harm that proposers reputation (i.e. has externalities due to real world economics). I.e. validator A withholds all signatures to the validator with the greatest delegation to self-bond ratio. Those delegators get unhappy with lower rewards and redelegate to others. The only risk validator A takes is slightly lower time to respond if they go offline (i.e. due to liveness slashes), which should be relatively negligible if the validator has confidence in their setup. I think this is a real problem.This is a complex problem. Suppose we only reward validators who actually voted on the block. Now when proposing a high value block, I perform the same attack in reverse, i ignore certain other validators signatures. In addition to increasing your relative proportion of stake, you again can do a targeted attack on other validators, which can cause lots of harm to their reputation. (i.e their delegators get sub-normal rewards, and redelegate) I think the best we can hope for is that ignoring out of protocol advantages, we construct a system such that the proposer's reward is lower if they withhold your signature, accounting for the relative distribution of stake if only those who should be rewarded get rewarded. Alternatively we could run the incentives in a scenario where everyone performs such an attack (either at the same highly-delegated validators, or randomly) what are the net rewards for doing so. (I imagine it would be a prisoners dilemma situation unfortunately)
From a conversation between me and @cwgoes
The text was updated successfully, but these errors were encountered: