[Proposal] [Draft] Proportional Slashing

Proposed Proposal Body: Context In the Cosmos Hub, centralization of consensus power amongst a small set of validators can cause harm to the network due to increased risk of censorship, liveness failure, fork attacks, etc. This centralization is negative externality which causes harm to the network. One of the most common methods of dealing with negative externalities is to “tax” the perpetrators of the externalities in order to shift the negative utility onto them. In this case, we would like a way to pass on the negative externality risks of centralization onto the large validators and their delegators in a sybil-resistant manner. Proportional Slashing Currently, any delegator will lose 5% of their stake if their validator double-signs. To better account for the risks of centralized stake-backing, we are proposing a new mechanism along with its associated governance parameters that can change how slashing works. We call this mechanism Proportional Slashing. In this system, instead of all delegators getting slashed at the same rate for faults, the rate a delegator gets slashed for a fault is proportional to the faulting validator’s percent of consensus power. This…

Excerpt (1195 of 4072 characters). Read the whole post on the forum ↗

For reference, I also have an implementation here:

cosmos/cosmos-sdk

:chains: A Framework for Building High Value Public Blockchains :sparkles: - cosmos/cosmos-sdk

I think this is a good idea and agree that proportional slashing should be adopted.

One thing that does stand out to me from this proposal is that the criteria to determine correlation seems a bit overly broad, at least for double signing.

An entire unbonding period (three weeks) is very long. Wouldn’t one expect that if two validators ran on the same infra and had such a failure, they’d double sign simultaneously or within minutes of each other?

Is there some way to do this objectively?

Another key thing will be to choose the parameters appropriately. Maybe it would be reasonable that a validator with 10% voting power would have 2x the slashing penalty of a small one? Or what kind of numbers do you think are reasonable?

Yeah, those times were just examples. Those are mostly upper bounds on how long it can be, because we can’t slash past the unbonding period. You’re probably right, it should likely be lower. Not sure what it should be for double sign, maybe an hour? I feel for liveness, it should be at least the length of the liveness tracking window.

These should probably be governance-controlled parameters can be changed with ParamChange proposals. I should probably just remove the examples from the proposal, as it might hang people up.

Another key thing will be to choose the parameters appropriately. Maybe it would be reasonable that a validator with 10% voting power would have 2x the slashing penalty of a small one? Or what kind of numbers do you think are reasonable?

For the k constant multiplier mentioned in the ADR, I did make that a governance parameter in my implementation. But so you think we might want the slash percent to be sublinear with validator size rather than linear?

The current design Sunny came up with is based on a square root formula, so basically the slashing percentage for a validator is equal to his voting power and in case multiple validators (n) are at fault, it becomes (sqrt(voting power validator 1) + sqrt(voting power validator 2) + …+ sqrt(voting power validator n) )^2

So for two validators:
Validator 1: 2% of the voting power
Validator 2: 4% of the voting power

The original double sign slashing percentage for each one is 2% and 4%. When both get slashed within the same timeframe for double sign, it becomes: (sqrt(0.02) + sqrt(0.04))^2 = 11.65% for each one of them.

If we take another example with the hypothesis of 3 validators having 1% voting power each:
(sqrt(0.01) + sqrt(0.01) + sqrt(0.01))^2 = 9%

and another one with 3 validators having 4% of voting power each:
(sqrt(0.04) + sqrt(0.04) + sqrt(0.04))^2= 36%

I like how elegant is the design, I think we can put upper and lower limits to the slashing percentage. @bharvest talked about starting at 1%, which could be a good idea. I would also suggest stopping at 50% or 33% so that the edgy case of 100% slashing can be somehow avoided.

Great proposal!

For reference, this is the current design and rationale for correlated/proportional slashing in Eth2.0: https://notes.ethereum.org/@vbuterin/rkhCgQteN?type=view#Slashing-and-anti-correlation-penalties

Here it states that in Eth2.0 the plan is to slash 3*voting power of other validators that got slashed within the length of what seems to be similar to a Cosmos unbonding period (so a linear increase and a long-ish consideration period).

Intuitively; it seems to me that the square root formula might punish correlated slashings for separate validators too hard in comparison to a single high VP validator (though I agree that there should be some factor that discourages validator sybils). Maybe there could be another parameter for single validators (let’s call it j) so that slash_amount = j * power (in Ethereum’s case j appears to be 3).

I also agree with the minimum slash. Otherwise it may become extremely cheap for small validators to double-sign (e.g. currently 0.04% for the 100th validator) and a maximum to avoid 100% slashing (don’t know what a reasonable limit would be here).

While I like the proposal I have some doubts about its real effect.
As we saw in Hyung statistical analisys of delegators, very few of them are aware of the risks of staking all their tokens in just one validator. They do not care at all, in average, about risks.
What they DO really care, acording that great analisys, is about profits.

My opinion is: As long as we do not modify the code in order to alter profits we won’t see any substancial decentralization effects.

Proposal assumes that delegators act rationally, we have seen in practice that they do not. I am in favour of the proposal even if it would not have intended effect as it might help to at least decentralize stake of rational delegators. Explorers should adapt and display information about what % of slashing penalty delegator should expect.

@asmodat We at RNS Solutions are developing explorer with some extra metrics at Antlia explorer.
We will add expected slashing percentage for each validator.
Excellent propsoal again from @sunnya97. Thank you

IMO this proposal is PLACEBO

I don’t think this proposal would have the effect of flattening the voting power distribution. In fact, it might have the opposite effect, and drive further consolidation of stake to a smaller number of large, well capitalized entities. Increasing slashing penalties for larger validators favors sophisticated and will capitalized entities who can afford to build infrastructures that are very unlikely to fault. Smaller validators are less able to invest in high quality infrastructure and technical operations, and are viewed as higher risk operations. A simple example is the use of HSM based key management, which even in a simple configuration reduces the risk of a double sign by a considerable degree. Many small operators are not able to afford (or choose not) to pay the cost of the physical infrastructure required, and instead use local software signing with plain text keys on disk. Because the risk of a slashing events can me mitigated by the larger operators, even with a higher cost of a fault their relative risk of loss may be lower than a smaller and less sophisticated operator. It is rational to select a 1% risk of a 10% loss over a 3% risk of a 5% loss (numbers for…

Excerpt (1190 of 3340 characters). Read the whole post on the forum ↗

Thanks for your work on this, @sunnya97

A few initial questions about your design choices:

1. Are you relying upon slashing events to drive behavioural changes? This solution only appears to make delegators directly feel the negative externality of centralization in the case that their validator gets slashed.
2. How can participants understand and manage risk, given a variable slashing rate that may change often and/or very quickly?
3. I’m having a hard time seeing how this is Sybil-resistant. Is equivocation a correlated fault? ie. if I’m running multiple validators and one of them double-signs, is there an increased likelihood that my other validators will do the same?

I find the different points you are raising interesting. Given that I am working on a slashing insurance product, maybe I can answer one of them: mattharrop: Finally, large operators will be better able to insure against slashing losses. As markets mature, sophisticated and well funded operators are likely to be able to acquire third party insurance against slashing, negating the increased slashing penalties. The cost structures inherent in offering financial products of this type advantage larger operators, despite larger slashing penalties. It will be more difficult for smaller operators to qualify for and afford such coverage, leaving them less able to compete. Well capitalized entities, such as centralized exchanges can self insure and provide full guarantees against loss. Very few operators other than large centralized exchanges have the available capital to offer meaningful guarantees of this nature. DeFi and building products on the blockchain allows to open the doors and let all the validators have access to “sophisticated products”. With the current formula, small validators will actually be advantaged; they would have a lower slashing percentage and…

Excerpt (1197 of 2345 characters). Read the whole post on the forum ↗

If a small validator’s fault is correlated with a large validator, as I understand it the small validator would be subjected to a large slash.

eg. validator A has 0.1% and validator B has 10%. If they have a correlated fault
(sqrt(0.001) + sqrt(0.1))^2 = 12.1%

This small validator just suffered a very large slash. This seems to be the opposite of the stated goal. Or am I misunderstanding?

Love the way you think. Everytime I am on this forum I get so excited about the COSMOS network.

Yes this is true and this math should be forcing small validators to decorrelate.

Basically if this proposal passes and both delegators and validators don’t take it into account (meaning delegators don’t start redelegating to smaller validators and small validators don’t decorrelate) then a case like this might happen.
But I get your point regarding the small validator moving from a very low slashing percentage to a very high one while the big validator sees a smaller change.

sunnya97:

We see a centralization of consensus power within the Cosmos Hub to a smaller set of validators over time, as can be seen through an increasing gini coefficient of validator voting power.

Hey @sunnya97, curious to know where you’re seeing the gini coefficient of validator voting power.
I just went through my records, and I’m sort of seeing a bit of the opposite ie. consensus power appears to have decentralized somewhat.

I’ve shown the Lorenz curve for April, July, August, September, and now October. Let me know if you’d like to see more in-depth data. Here are the table summaries:

As an aside, it appears that only Sikka’s power has been increasing steadily and rapidly. Using gov power charts because gov power is equivalent to consensus power:

Basically if this proposal passes and both delegators and validators don’t take it into account (meaning delegators don’t start redelegating to smaller validators and small validators don’t decorrelate) then a case like this might happen.

I don’t think it’s been shown that small validators can effectively decorrelate, and even if they could, they have no way to reliably signal this to delegators. Since it is impossible to accurately estimate correlation risk, a rational delegator will evaluate the slashing risk as though validators are highly correlated.

But I get your point regarding the small validator moving from a very low slashing percentage to a very high one while the big validator sees a smaller change.

Given this, the proposal fails to achieve it’s stated intent.

I have to agree with @mattharrop here. It’s difficult not only to decorrelate but also to signal and externalize this. Amongst smaller validators, there are only so many varying infrastructure setups and cloud providers.

Gavin:

I just went through my records, and I’m sort of seeing a bit of the opposite ie. consensus power appears to have decentralized somewhat.

Great point. Admittedly, I didn’t actually calculate the Gini change over time. I guess I meant more that there is a high Gini coefficient, rather than necessarily an increasing one. I removed reference to Gini coefficient altogether from the proposal.

mattharrop: Increasing slashing penalties for larger validators favors sophisticated and will capitalized entities who can afford to build infrastructures that are very unlikely to fault … Imo, this is exactly the type of validator we want to incentivize. Validators should be investing into their hardware and security setups. mattharrop: Small operators are more likely to have similar infrastructure, deployed in similar configurations, with identical software stacks. Many small operators do not use hardware based key management, leaving them all vulnerable to similar risks, which will correlate across diverse cloud infrastructures. And by doing this, they are causing a massive negative externality harm to the network in the form of resilience decrease. This procedure is to incentivize them to not do that. mattharrop: The incremental cost to large operators to split their operation into a number of smaller validators is small, even if they do so on diverse infrastructure. If they do this, it is beneficial to the network, as it is helping make the network more resilient. Gavin: Are you relying upon slashing events to drive…

Excerpt (1199 of 3195 characters). Read the whole post on the forum ↗

mattharrop: and even if they could, they have no way to reliably signal this to delegators. Since it is impossible to accurately estimate correlation risk, a rational delegator will evaluate the slashing risk as though validators are highly correlated My answer might sound a bit light on this one but I am a strong believer in free and transparent markets. And transparency is what DeFi brings. One of the use cases of the slashing insurance is actually to have a risk score for each validator calculated out of the premiums that were bought for each particular validator. The higher the insurance premium price, the more risky the validator (from a slashing risk perspective). For a validator, one way of signaling is to make sure that the market (especially the risk buyers) are aware that they are doing everything needed to decorrelate and publish/show case what they implemented. This will push the market to price that particular validator risk at a lower price. The same way in traditional markets price is seen as taking into account all available informations, the premiums prices will be taking into account all available infos the validators make available. All the data…

Excerpt (1194 of 1254 characters). Read the whole post on the forum ↗

Isn’t slashing is already proportional (ie. 5%)? What is your goal by redistributing the slashing amount–is it actually to drive a change in the gini coefficient? Do you have a gini coefficient target in mind?

Heads up, that the ADR has been updated: github.com cosmos/cosmos-sdk/blob/master/docs/architecture/adr-014-proportional-slashing.md ``` # ADR 14: Proportional Slashing ## Changelog - 2019-10-15: Initial draft ## Context In Proof of Stake-based chains, centralization of consensus power amongst a small set of validators can cause harm to the network due to increased risk of censorship, liveness failure, fork attacks, etc. However, while this centralization causes a negative externality to the network, it is not directly felt by the delegators contributing towards delegating towards already large validators. We would like a way to pass on the negative externality cost of centralization onto those large validators and their delegators. ## Decision ### Design To solve this problem, we will implement a procedure called Proportional Slashing. The desire is that the larger a validator is, the more they should be slashed. The first naive attempt is to make a validator's slash percent proportional to their share of consensus voting power. ``` slash_amount = k * power // power is the faulting validator's voting power and k is some on-chain constant ``` ```…

Excerpt (1192 of 1394 characters). Read the whole post on the forum ↗

I believe as well it would not have a sufficient desired effect with a view to achieving more decentralization. IMHO, paying a flat amount per node as a percentage of the overall inflation is the better solution. Different from a slashing risk fear induction, I believe getting a higher reward for staking on a low staked node is a truly scalable and working solution. It solves the centralization and unsustainable node problem, and as well it provides a kind of masternode price tag giving value to Atoms.

What stops someone from just running many nodes?

Nice to see some discussion goin on. Here are a couple of our concerns: • If you’re taking all this at face value, isn’t this making decisions based on nothing but assumptions? Based on the time frame they failed in, you’re essentially relying on guesswork to slash validators that are likely (!) to run the same setups. I think we can agree that this is not ideal. Actually, there might not be an ideal solution to this, who knows. • What stops large validators from running multiple validators with different setups? Let’s assume you are one of the currently 125 validators in the set. One of these 125 setups is known to you which is your own one. You don’t know anything about the setups of the other 124 validators. By splitting up your validator into two validators you’ve increased the amount of known setups to two, decreased the amount of unknown setups to 123, pushed out a small validator from the set therefore slightly increasing everyone’s voting power and reduced the risk of having correlated setups. If I now have one setup that is unique and one that many others have, doesn’t this reduce the amount I’m getting slashed? • How do you think the amount of different setups…

Excerpt (1199 of 1758 characters). Read the whole post on the forum ↗

Interesting to think about the true cost of large validators splitting up to get around this, and whether the cost to do this would be less than the benefit gained by small validators. Would be good to hear from small validators if they think this will really be helpful, or just further penalize them due to the cost of decorelating. Obviously decorrelating is something we should aim for, but maybe wonder if forcing it like this might have unintended consequences. Of course for this to help small vals in the first place the penalties for slashing when its just them faulting must be less than they are currently. Wonder if there’s other ways to work towards validator decentralization we could consider. Some random ideas (may or may not be good): • smaller rewards for larger validators (penalty would have to be small enough that its not worth it for them to split into multiple smaller validators …) • higher cost to delegating to large validators (maybe you have to burn some atoms as a function of the validator’s voting power, or pay into the community pool, or pay a higher fee) • forced distribution of delegation ie. some fraction of a delegation to a validator is distributed…

Excerpt (1197 of 1685 characters). Read the whole post on the forum ↗

ebuchman:

Interesting to think about the true cost of large validators splitting up to get around this, and whether the cost to do this would be less than the benefit gained by small validators.

It’s already happening, to some degree - infrastructure-as-a-service companies that run whitelabel validators on behalf of others are essentially a single validator in terms of network security since they control the consensus keys. Once it’s fully automated, it’s trivial to deploy additional instances.

The cheapest and most correlated way to run a lot validators would be a modification to the node software that votes on behalf of multiple validators.