IMO bug… At least for Validators not in the active set. Not governance vote-worthy.
I’m actually trying to come up with ways that it might pose as a valid attack service for non-active Validators to have voting capabilities but can’t think up any right now. Any ideas?
The jailed Validators getting a vote however could be debatable. Seems like if you’ve been jailed it’s because you’re not helping the network and are “in quarantine” in a sense (sorry if this is too close a word choice for current affairs in the world), away from the network, so it wouldn’t make much sense for this entity in “quarantine” to have any vote in governance issues.
I agree. I think that bonded ATOMs should have voting potential, even if the validator isn’t in a position to be slashed ie. not in the active set of validators.
Currently that’s not the case, and I think we should fix it in the next upgrade.
Came up with a nefarious, quasi-attack vector for why non-active validators SHOULD have their vote count…
If there is a very, very close votes it opens the door to large Validators to Sybil up their active Validators and split out their staked Atoms in order to negate smaller Validators’ votes which might be counter to their vote, and they turn them into inactive Validators, in order to decide close governance vote decisions.
I think it is the agreed risk upon delegation to each validator.
Delegators take risk of several things which can be happened by validators
double signing slash
commission hike
vote change right before tally
risk of being out of valset during governance voting period
The stated risk is just one of the risk exposed by the decision of delegation on a validator.
We cannot completely remove this risk, and redelegation can always provide a way to protect governance vote rights from this risk.
So I think it is not a bug or not a thing to be fixed.
What is more important on this context is the overwriting of delegators’ votes from validators.
I think it is a bug to be fixed as soon as possible.
My understanding from @sunnya97 is that validators that are not in the top 125 are currently unbonding or unbonded, which means they have or will have access to their stake. Is this the same for their delegators?
Perhaps it makes sense for the current implementation to remain as-is (in which case I think we should educate stakeholders).
On the other hand, we could change the software so that staked ATOMs remain bonded and count toward a vote, even if the validator has been removed from the active set.
I could see an argument for both. I think that this deserves some broader discussion and possibly a vote.
My understanding from @sunnya97 is that validators that are not in the top 125 are currently unbonding or unbonded, which means they have or will have access to their stake. Is this the same for their delegators?
Unless I’m mistaken, the validator begins unbonding as soon as it drops below the cliff (gets kicked out). It then waits the full unbonding period like any other situation. However, it’s shares and its delegates are still bonded to it.
On the other hand, we could change the software so that staked ATOMs remain bonded and count toward a vote, even if the validator has been removed from the active set.
I believe this was @sunnya97’s proposal – to not iterate over bonded validators but iterate over all validators when tallying.
I think it makes sense to withhold voting from validators removed in the event of being tombstoned or jailed. But I agree that those knocked from the active set through no fault of their own should have their vote count in some way.
Alternatively, could there be some conditional type logic added to the voting portion of the software for delegates. That way its kind of like a ballot, and those delegates who are active enough to participate in governance can still stake with the validator of their choosing IF they are in the active set, or otherwise shift their vote to adopt that of another validator IF the validator they are staked with is not in the active set. That way delegates are more incentivized to actively participate in governance to make sure their vote counts one way or the other, and it prevents against the type of attack @JesseLivermore described.
Idk how technically feasible something like this would be or if it would be worthwhile, but popped into my mind reading through some of these comments.