Make a slash governance proposal

[ValarDragon]

Summary

There should be a governance proposal type to slash a validator. It would specify slash_percentage and validator address.

Problem Definition

This has a number of use cases. It allows blockchain communities to codify social standards that validators have to adhere to, and in the event they are 'caught' by the community, it allows them to slash them on-chain. (Without needing a hard fork)

A social slashing standard that has interest from the Osmosis community is essentially a "No Sybilling" condition, where they can all agree that if governance is presented with sufficiently persuasive evidence of a validator sybilling in order to game airdrops, newer staking reward designs, etc. they would be slashed for a certain factor. (With some carveout for cotenancy situations etc.). This is in part motivated by some validator-sybil-gameable decentralization ideas, cref https://commonwealth.im/osmosis/discussion/2036-proposal-per-validator-epoch-bonus-for-better-decentralization

I'm generally of the view that this is important for many chains, if validators commit malicious activities not yet thought about in advance, or on other chains. I propose we add this as a governance proposal type to the slashing module. Chains can simply choose not to add this governance proposal type to their governance router if they don't want this feature.

Proposal

Make a new governance proposal type in slashing with the following proto:

message SlashValidator {
  option (cosmos.msg.v1.signer) = "authority";

  string authority = 1 [(cosmos_proto.scalar) = "cosmos.AddressString"];
  string validator_address = 2 [(cosmos_proto.scalar) = "cosmos.ValidatorAddressString"];
  string slash_factor_percent = 3 [
    (cosmos_proto.scalar)  = "cosmos.Dec",
    (gogoproto.customtype) = "github.com/cosmos/cosmos-sdk/types.Dec",
    (gogoproto.nullable)   = false
  ];
}

Then implement that message in slashing message server and do the authority check.

EDIT(@julienrbrt):

• Updated issue to match gov v1.
• Higher quorum is solved by message based params (already implemented)

  ---

For Admin Use

• [ ] Not duplicate issue
• [ ] Appropriate labels applied
• [ ] Appropriate contributors tagged
• [ ] Contributor assigned/self-assigned

[alexanderbez]

I would agree we'd need higher quorum requirements on this type of a proposal, but in general, I think it's a neat idea 👍

[faddat]

Dislike: provisions for cotenancy and hosting cos that do the ops for many validators

I honestly do not think that the white-label shops are deserving of protection, particularly if they boast of running validators on networks from the same kube cluster.

It isn't safe and is worthy of the slash imo.

Validators run nodes..... Unless we want validation to devolve into a purely political role

Like very much: Allowing users the ability to enforce social standards

To some degree this goes against my learnings from Juno prop 4, but it really does resonate with me.

2nd note on white labeling

I suppose that it is one thing, to operate many machines for many validators in many places....

and another to toss e'm all in us-east-1 and pray (etc, etc)

[hleb-albau]

okey, let's do it start working on it will create a draft to discuss shortly

[hleb-albau]

I created a small draft, now lets discuss next:

1. What validator state should be considered for slashing(now, proposal creating or other)? How it should influence delegations and re-delegations before and after slashing point? Should we allow safe re-delegate tokens during vote or during deposit or not?
2. What if chain has unbounding period is less than vote period? (maybe just leave it as is, just make sanity check before call actual slash). We loose info about delegations and re-delegations after unbound succeed.
3. Can validator and its delegators vote on prop?
4. It seems that gov module has very simple route handler that not allow to register more advanced checks on proposal creation. For example, it is not possible to validate on proposal creation that validator exist and in active set. Maybe we need to advance route architecture?(or it should be done in ADR in other issue?)

[alexanderbez]

I don't think we can proceed with this proposal until we can have custom quorums per proposal type. That is a strong prerequisite IMO.

[ValarDragon]

Why is that a strong pre-requisite? Chains can just elect to not include this in their governance router

[alexanderbez]

True, but it's going to exist in the SDK and ppl are going to copy it/use it without realizing that such a prerequisite should exist.

[ValarDragon]

Re the questios:

1) I think the only way to do it efficiently in the SDK atm is Now. That will cover unbondings / redelegations though. 2) Hrm, I think thats an ok edge case. Would be good to potentially emit a warning if theres a sensible way of doing so. 3) Yup! If your being slashed, you should be allowed to say that you don't agree 4) Yeah, this is really unfortunate that none of the relevant validation methods get the context passed in. I think for a v1 of this feature, we'd have to be ok with the edge case of being able to slash inactives.

[ValarDragon]

Re: Safety checks, ok if thats the decision, will recreate the issue in the Osmosis fork. Seems like progressing in the SDK on this would be blocked for several months due to the exciting gov refactor!

[alexanderbez]

Is this work really that complicated? It seems extremely trivial to me, unless I'm missing something...?

1. Add a new x/gov param that controls quorum for proposal types
2. Implement SlashValidatorProposal which is just calls Slash with proposal defined values (i.e. validator, amount, etc...)

[lukevenediger]

Is this work really that complicated? It seems extremely trivial to me, unless I'm missing something...?

1. Add a new x/gov param that controls quorum for proposal types

Would this mean using the proposal type as a key for setting a specific quorum value in params?

[julienrbrt]

This comment not actual anymore, I have updated the issue on the 19 feb to match with the latest gov changes.

Higher quorum is solved by message based params (already implemented)

So no need to do there.