Change governance to auto-abstain instead of slashing

[cwgoes]

Otherwise our incentives will just cause validators to utilize scripts to auto-abstain, then (possibly) vote yea or nay later in the voting period. This is already happening on the testnet, and it will likely persist to the mainnet since auto-abstaining carries no penalty and prevents possibly being slashed.

cc @sunnya97 @jaekwon @gamarin2

[fedekunze]

Maybe we could just lower the amount that validators are slashed ? We definitely have to come up with something to incentivize participation on governance in a way that's not faked (like using scripts for example)

[FelixLutsch]

An idea could be to set a minimum deposit for proposals to get accepted to incentivize well-thought through proposals and implement some form of proposal crowdfunding mechanism, so that it becomes possible for smaller stakeholders to start proposals.

[ValarDragon]

We definitely want the entire validator set to vote and not auto abstain imo. (Auto abstaining doesnt feel like it achieves what we want)

Min deposits are already implemented. I think we just need a higher min deposit set, and we need to rate limit new proposals. We also should increase the time window for voting.

[rigelrozanski]

I second Val - I think auto-abstaining is counter productive. we WANT validators to get slashed if they don't participate. If validators want to write scripts to auto-abstain so be it - it should be their own choice to do so, not the default action... Honestly I think governance should even create proposals to slash anyone who sends an abstain vote to the proposal (even for there first vote) to detect algorithms

[cwgoes]

I second Val - I think auto-abstaining is counter productive. we WANT validators to get slashed if they don't participate. If validators want to write scripts to auto-abstain so be it - it should be their own choice to do so, not the default action... Honestly I think governance should even create proposals to slash anyone who sends an abstain vote to the proposal (even for there first vote) to detect algorithms

What about removing the option to abstain? Too radical?

[ValarDragon]

I think abstaining is an important part of governance -- acknowledging that you have read through it and don't want to vote. Also I don't see how removing the option to abstain relates to the original issue being cited here.

[cwgoes]

I think abstaining is an important part of governance -- acknowledging that you have read through it and don't want to vote. Also I don't see how removing the option to abstain relates to the original issue being cited here.

Because it means that auto-voters would have to choose yes or no, which is more risky. I agree that abstaining is a useful option, and I guess requiring that they write a script to do it is a slightly better default than doing it automatically - but I'm not convinced that our current mechanism incentivizes what we (presumably) want to incentivize: validators reading a proposal, evaluating it rationally, then voting. Maybe a better mechanism doesn't exist, but seems worth a little brainstorming.

[sunnya97]

If validators want to write scripts to auto-abstain so be it - it should be their own choice to do so, not the default action...

I cannot imagine any legitimate validator not running a script to auto-abstain. Forgetting to vote seems like one of the easiest ways to get slashed and running a script is such an easy way to avoid this. Any rational validator will run such a script. Many of the testnet validators already are.

What about removing the option to abstain? Too radical?

Then all the validators would then just run scripts to auto-VoteNo. Is this better than auto-Abstain? Idk.

From a chat with @gamarin2 :

Yes, this wasnt an issue in original design because you could vote only once Maybe a solution is to prevent vals from changing their vote

But then he realizes that this doesn't work as well because

I guess you can still autovote abstain one day before end of voting period though

---

I think slashing for nonvoting might just not be a good mechanism. It seems like its just adds computational overhead and is not really going to help achieve our desired outcome.

Perhaps it is better to brainstorm how to make social norms encourage voting, and there be reputational repercussions, rather than in protocol slashing, to not voting.

[gamarin2]

There was a penalty for not voting mentioned in the original whitepaper. I think originally it was a revokation and not a slash, but the problem of auto voting for not getting punished stays the same. I think it might be good to ask @jaekwon here.

If we can't prevent validators from autovoting, maybe we can make it more apparent when it happens. For example, we could add a mandatory "justification" field when validators cast a vote. Keeping the slashing mechanism would "force" validators to vote, as originally intended, and the "justification" field would help spot autovotes.

[sunnya97]

Even if there was a mandatory "justification field", what to prevent my script from just filling it with random garbage?

[gamarin2]

Nothing, thats not the point. The point is to help distinguish autovotes from actual votes.

[fedekunze]

I think @FelixLutsch has a point here. We should rise the minimum deposit and make a crowdfunding mechanism to avoid having fake autovotes that are generated with scripts.

[ValarDragon]

I like the idea of requiring a reason. This seems like an effective approach to me. I think it will be apparent to delegators then what the reasoning was / how their validator is making decisions. We should also allow this field to either be large, or expect it to link to a centralized service ran by the validator. I actually think this aligns incentives in a "good enough" way. If you auto-vote w/ a script, its obvious to your delegators that you have done so - which I think is sufficient.

I do think we should still raise the min-deposit signficantly and rate-limit, independent of incentive alignment. If reason is fairly simple to add pre-launch, then I guess we can do that as well.

[rigelrozanski]

wow I'm totally into this justification field!

Just brainstorming here, I also think as a validator is would make sense to have a script to auto-abstain your vote as a last minute if for some reason you forgot to vote, which I guess makes sense - so if that's going to happen anyways then probably building it right into the protocol would be OKAY - but counter to that there is also there is a difference between how votes should be tallied for abstain vs. non-voting.

so instead - I'd propose that there should some basic threshold of missed votes before you're which slashed (which is quite low) - for example, you can forget to vote up to 5% or 10% of the time and that's okay, any more and you get slashed. This probably drastically reduces the desire to write a script, as people would detect it anyways if you'd also have to add a justification field (a point which I can not stress how much I love).

unfortunately - script detection will probably have to go through governance to slash a particular validator. It would also be fun to slash all the validators if nobody chooses to make these proposals. There would need to be some kind of incentive/easy anonymous submission I think for the proposal written otherwise validators might choose to collude to not slash each other.

[sunnya97]

I'm okay with having a justification field (I was already thinking people would do this through the Memo of their tx), but like I said we should use this for social repercussions, rather than in protocol slashing. If I can avoid the autoslash by just putting a non empty string for justification, I'll still have a script for auto doing that.

My point is that because the autoslash is always beatable, let's remove the functionality in the code, and leave it to social repercussions, which may include slashing through governance. (I personally don't like that, but that's another discussion.)

[7alisman]

We all can recognize that there is a considerable difference between the consequences of voting (or not voting) on testnet vs mainnet, Currently, with a ~20min voting window on testnet (vs 2 weeks on mainnet) scripting is mandatory. To be frank, even with an alert setup, I just find it difficult to justify getting up at 4am, in a <20 min window, to rush to my computer and vote on the 9 proposals submitted by the same user as a test.

I firmly believe that the minimum deposit should be large enough to act as a deterrent for a SINGLE user to submit, and should almost mandate the use of crowdsourcing. I also think that there should be a limit to the number of proposals a single validator can have up at any given time.

At the same time, I also believe there needs to be an incentive to participate in governance, but I think trying to detect, and punish scripting is overcomplicating the solution.

I like the idea of mandating a justification, but I also feel that could be expanded to all voting options, and not just abstaining. If then the justifications were made public and readily visible for all delegators and validators to see it would lend more to social/reputational equity (delegators could then potentially pick and choose validators based on their voting habits as well).

Further to that, as far as preventing scripting, why not expand on the abstain feature. Allow the protocol an auto abstain feature for X number of consecutive votes, and instead of offering 1% slash per missed vote, slash 1% per missed vote when your threshold reaches X (ex: 3 auto abstains = 3% slash). This way, if someone manually chooses to abstain, they can provide their reasoning, but users aren't immediately punished for missing a vote.

This will not -prevent- auto scripting, but by making the auto-abstain, or abstains public it will effectively create a "wall of shame" and eventually lend itself to the social repercussion @sunnya97 was speaking of.

[mdyring]

Agree with @sunnya97 and @cwgoes that not voting should be interpreted as abstain ("auto-abstain") instead of slashing. Since it can be scripted anyway, most sensible validators would setup scripts to do this at the last minute. In light of this, it doesn't make sense to slash.

The idea of providing justification is interesting, but validators should not be forced to provide it. They might not want to (for whatever reason) and could potentially be self-staking only, and thus not required to justify themselves to anybody. So must be optional.

At the end of the day, I imagine most delegator will focus on fees and infrastructure when picking validators (i.e. their own bacon), and pay less attention to politics.

I think a good first start would be to auto-abstain for launch. Lets not delay due to this, as we can always vote on a new governance mechanism later on ;-)

[ValarDragon]

The justification field should be mandatory. If as a validator you don't want to make a justification, just put "_" or smth. Its not like were going to check for valid sentences in the state machine.

I prefer the situation where every validator must provide a justification, even if they choose not to vote, over the situation where noone votes and theres no statements as to why. Slashing for no vote achieves this well.

I'm fine with validators having scripts to vote "abstain" on the last day if they haven't already voted, I don't see why this is a big deal. Its now more clear to delegators in protocol what the situation. This is far more preferable than solely from Twitter imo. (If your validator has nothing this-proposal specific in their message, its clear that they are using a script)

If we increase deposit and rate limit, there shouldn't be too many proposals for validators to deal with, so we can reasonably expect them to always respond even without scripts.

I think the concern for scripts has blown up a bit due to our testnet having no rate limiting, and a low voting period, and only some validators having scripts built. For rate limiting, I'm thinking of a cap of 1 proposal beginning its voting period every 24 hours. (We would then have a queue for proposals with sufficient deposit but waiting due to rate limits) This is sufficient with a 2-3 week voting period to expect manual review from all validators, eliminating alot of the script fears.

[mattharrop]

The scripting is in place due to the short vote window, the fact that votes don't matter, and the psychological aversion to repeat slashing. With 2-3 week vote period and proposals that presumably will have impact on atom holders and validators, I doubt that the scripting that is incentivised on the testnet will carry over to main net.

[jeelimm]

I agree with @mattharrop that the short vote window has been problem within the testnet. But also, there was no notification made to validators so that they could be aware of the existence of governance proposals. Some of the validators seemed to be panicking after slashing occurred.

2 weeks voting period on mainnet seems reasonable, and as long as there is some kind of notification on new proposals, validators should be fine with that.

Regarding auto-abstain, auto-abstain should only be applied at the last moment of the governance proposal (before running out of 2 weeks), and abstaining should also be considered as a 'right' of silence, just as 'yes' or 'no'.

I'd also love to see if there should be a "standard" of which topics / issues should be brought up as a governance proposal.

[kwunyeung]

I agree with having the justification field and it should be mandatory. The validators should vote for what benefit to the network and their delegators. The justification field is for everyone to understand better the reason behind the votes.

Autovote is not a good practice. Validators have the obligation to read, understand, discuss enough and vote for the proposal. Even voting for abstain is for a reason, not just "I forget to vote". If a validator misses a vote, slashing is a very reasonable punishment (to reflect incentives to the voted validators).

Using scripts to auto-vote is also not a good practice. Validators have to leave the keys and passwords on the servers connecting to the network. Instead, validators should focus on monitoring/alerting system to know when there is a new proposal. And then they vote with the keys they store in local devices.

Higher deposit, a minimum number of depositors are good suggestions to let validator submit a higher quality proposal. As long as they need to have a high cost to submit proposals, they will take it seriously and not acting like what is happening on the testnet. The tests are like auto submitting proposals to slash other validators.

I would like to see an environment that validators won't discuss or gossip before submitting a proposal. They have to take their own risk to propose. And the proposer should convince other validators to support the proposal by depositing more stakes.

[melekes]

I am no way an economic expert, but I think validators will use any means to avoid deciding if a proposal does not affect their income. No captcha won't help you (they will hire a person to click on abstain from voting).

If I were a validator, I'd like to 1) get a notification via my preferred channel of comms (email or telegram or something else) 2) see clear consequences of any action or absence of such (i.e., each proposal should have a "Consequences" section with positive/ negative/neutral fields as we do in ADR)

[jackzampolin]

For rate limiting, I'm thinking of a cap of 1 proposal beginning its voting period every 24 hours. (We would then have a queue for proposals with sufficient deposit but waiting due to rate limits) This is sufficient with a 2-3 week voting period to expect manual review from all validators, eliminating alot of the script fears.

I would push back against this. With this in place it would be possible block the queue with spam proposals pretty easily.

[ValarDragon]

That's not true if there's a sufficiently high deposit. Each governance proposal is effectively a hub improvement proposal. There's currently only 1400 eips. (Alot of which aren't even real proposals) Perhaps we make ours 12 hours rather than 24 hours. That would mean in 2 years well have support for the same number of eips. There is a high social cost to a proposal, it should indeed be costly and rate limited. Remember anyone can contribute to a governance deposit.

[gamarin2]

I'm against rate limiting, I think playing with MinDeposit is enough and actually gives more flexibility.

I'm also against in-protocol autovoting, as it would further delay launch.

[iammelea]

we (validators) need more blocks for a vote, like more 5k, for the time's zones and for more. so only 200 blocks for a vote is not ok.

[gamarin2]

we (validators) need more blocks for a vote, like more 5k, for the time's zones and for more. so only 200 blocks for a vote is not ok.

This is testnet setting. Mainnet will have voting period of two weeks.

[iammelea]

yes, I am talking about testnet. we need 24hours windows for a vote in testnet. not 200 blocks. all validators are agreed in this. we don't need auto-vote, auto-abstain, scripts or so. we need time to can vote. ;)

[fkbenjamin]

As someone who is running an auto-voting script on the testnet, I understand that this would be very critical on a mainnet. @7alisman explained really well, why someone would run auto-voting on the testnet. I first just received an alert for every new proposal to then vote manually, but the issue was that at one point I received 50+ alerts over night. So I started auto-voting just to avoid slashing when someone is testing the feature.

I honestly think we don't need to change anything (except voting period of course) for mainnet. Every validator should take voting very seriously. First of all, proposals could potentially threaten our business model (what if there is a proposal to stop block rewards...), so every validator should watch them closely. Good governance to improve the network is key to see Cosmos flourish, therefore increasing the value of our stakes.

Second, reputation is one of the key assets validators can use to differentiate themselves from the competition. Do you rather delegate to someone who actively tries to represent the opinion of his delegators or someone who always abstains from voting? Therefore I think that "auto-abstainers" will lose delegations, which will turn them to manually voting.

Third, I don't think that a 'justification' on-chain will improve the situation. It's not hard to write a little tool that takes the text of a proposal and creates a statement like "I don't have a strong opinion about ABC..." from it. It would just create more sophisticated auto-voting tools and basically would hurt "engaged"/manually-voting validators, because they have to take the time to write down a justification.

Overall, just keep proposals as simple as possible and increase the voting period. One slight change we could think of is preventing the change of a vote. So if someone has voted "abstain" he cannot change it afterwards. This would make auto-voting really dangerous and would force validators to think well before they vote.

[joepindar]

I agree with @fkbenjamin. I see no need to change anything in governance - aside from the voting period in mainnet. I don't see the current situation as an auto-voting/governance issue, but rather as a "mindset test".

In gaia-8001 a situation was artificially created where validators could get slashed with ease. A 20 min voting period is impossible to manage over a sustained period with a manual process. Coupled with @zmanian highlighting the issue in chat before the avalanche of votes started suggests this situation is entirely manufactured.

Why? I believe it is a preparation for GoS... Given an adversary is attacking your validator and you are being slashed... what are you going to do about it? Some opted for a scrappy, less than perfect script to minimise some of the downsides. Others chose to continue with the manual process or ignore it as a passing issue for gaia-8001... Each approach is valid, but also shows part of the mindset of the team behind the validator.

If this was GoS, and there were Atoms on the line... and an easy mechanism to slash other validators was available... would your (validators) approach be different? Would you be spamming governance as well to get people out of the game?

In summary, I believe this is a test (without pass or fail) to make teams think about how they will respond in GoS.

$justification="For philosophical reasons too nuanced and complex to fit in this field."

[cfl0ws]

I don't feel validators should be punished for auto-voting. I do feel a validator's voting history should be easily accessible. This way delegators see how validators vote. The delegators can then consider voting history when choosing a validator.

This visibility allows a delegator to align with the values of a validator. In this case the validator's voting history expresses their values. If a delegator wants to delegate to an auto-abstaining validator, so be it. It may be that delegators view auto-abstaining validators as neutral parties.

I feel this is another instance of delegators having power to shape the network. The challenge is how to incentive delegators to make decisions to benefit the network.

P.S. - If a validator is managed by a DAO, the DAO could be used to determine how the validator votes. As Aragon One's product manager, I'm particularly interested in this use case.

[chenatu]

I think we should refer to real politics when thinking about blockchain governance. Delegator should not lose the right to select senator (their atom) when the senator does not do his job well. The first thing is to build a transparent and open governance environment.

I support the mandatory verification/justification field to the autovote and optional reason field to clarify the reason of voting. I do not support the slashing and prefer to some proportional unbound atoms way.

[ValarDragon]

Upon further thought, I actually agree with removing slashing here. This solves very easily the problem that if person A delegates to validator B, person A votes, validator B doesn't, A still gets slashed under the current implementation. Building a way to handle that effectively given how we do validator bonding pools would take lots of development time / delay launch. I think we should revisit governance slashing #postlaunch, but absolutely remove it now.

(Still 100% in favor of the required justification field)

[rigelrozanski]

@ValarDragon what are your thoughts on punishments in general? such as unbonding some tokens?