Normalize slashing penalties by total supply

[alexanderbez]

@cwgoes commented on Fri Jun 22 2018

I think we might want to normalize slashing amounts by the total supply. Currently, the spec calculates slashing amounts in proportion to validator shares, which are just bonded tokens.

In between when an equivocation is made and when it is discovered, the total token supply will change due to inflation. This would have the strange property that later discovery of evidence means a (slightly) lesser penalty, since the tokens which would have been burned if the evidence was discovered earlier can be inflated as usual until the evidence is actually discovered.

With our current unbonding period and inflation parameters, the difference is minimal, but we (or governance) might want to change those parameters in the future.

If we change the calculation to slashedTokens = slashFraction * totalBondedTokensNow * (validatorBondedTokensAtEquivocation / totalBondedTokensAtEquivocation), it changes the semantics to "slashed as if the validator double-signed now with the power they had at the time of equivocation", and means that slashing penalties are just as severe if evidence is discovered when the unbonding period is almost over as if it were discovered immediately.

cc @ebuchman @rigelrozanski

---

@rigelrozanski commented on Sat Jun 23 2018

hmm let’s think about this a bit more

• I don’t think it matters so much if the total supply has grown, BUT I reckon it may matter if my % of total voting power has increased due to there being less bonded tokens. This could be caused by other people bonding/unbonding tokens or folks getting slashed.
• Under the situation that during discovery time each misbehaving token now holds LESS voting power (relative to bonded-supply) than it did when it was used to commit a protocol breach then, yes, I agree that even more tokens should be slashed;
• HOWEVER I do not think we should slash less tokens under that opposite situation that each token now holds more relative weight - because really, they should have been slashed at that rate earlier on

…Does what Im saying make sense?

---

@rigelrozanski commented on Sat Jun 23 2018

aka:

if bondedSupply@breach > bondedSupply@discovery
   each token is now worth less than they it used to be worth,
   so slash more tokens than just %slashing*tokens-that-committed-crimes
else
   slash no less %slashing*tokens-that-committed-crimes

---

@rigelrozanski commented on Sat Jun 23 2018

@cwgoes documentation of the slack conversation

cwgoes
I agree; I think I picked it up from some documentation somewhere but we can definitely pick a different word
Also, you're right, I implicitly assumed the entire supply was bonded when thinking about this but that won't necessarily be the case
We don't want to slash more or less for bonding/unbonding unrelated to the validator in question
(as evidenced by the issue title and body conflicting, lol)

rige
(document this conversation in the github?)

cwgoes
I will, but I want to make sure I understand your points first
I do think that it matters if the total supply has changed
Say we had high inflation, a long unbonding period, and everyone kept their inflation rewards unbonded (simple case) (edited)
Now there's a large difference between evidence being discovered immediately and discovered near the end of the unbonding period

rige
Yeah let’s say that it takes nearly the full unbonding period to discover

cwgoes
In the latter case (late discovery) the bonded steak continues earning inflation rewards for most of the unbonding period

rige
I guess the validator shouldn’t of received some of that inflation reward? is that what you want to counteract? (edited)

cwgoes
In the former case (immediate discovery) it is slashed immediately and earns much less
Yes

rige
hmm yeah okay BUT that means that you’re slashing bonded tokens to make up for unbonded tokens that you’ve received - seems counter-intuitive, I mean under a situation where we have a much longer unbonding period (on the orders of months) then yeah this may start to be an issue I guess (edited)
But I could also imagine a scenario, where you just get slashed 100% (or more!) of your tokens due to the back calculation
I almost think the perpetrators should just get to keep them

cwgoes
No, that should never be possible (getting slashed over 100%) (edited)
How do you mean?
Oh I guess if inflation is ludicrously high

rige
I reckon it is! here, imagine an unbonding period of a year with 100% inflation
yeah ^
but I guess that’s an edge case which is fine, we just need to add a check to make sure not more than 100% is attempting to get slashed so we don’t panic

cwgoes
We do that anyways
I agree it's kinda messy to slash bonded tokens for unbonded rewards (edited)
I still think it's more accurate than not normalizing at all though

rige
cool - BUT what I was saying I don’t think it matters, I almost like the idea of adding more incentive for the network to not be lazy about catching the bad-guys
like so what they made off with a bit more inflation $ - our bad for not catching em!
not to mention that for any real crime, the extra inflation $ is going to be << than the %slashed
I don’t think it negatively affects the functioning or ideals of the network if the perpetrator get’s to keep inflation $ if they’re problem is not detected instantly

cwgoes
It does seem unlikely to be too detrimental in practice
But the current model (without normalization) does oddly change the "unbonding period security" to be (even slightly) uneven over the whole period, and makes the degree of uneven-ness dependent on the choice of unbonding period and inflation constants (edited)

rige
Was the unbonding-security always uneven anyways? There is more opportunity to not be caught and continue to act out-of-protocol as more blocks pass during an unbonding period (edited)

cwgoes
If there was no inflation, the slashing amount would always be the same (relative to total supply)?
Security model A: light client coming online every 20 days
Security model B: light client coming online every other day
If both are otherwise identical (can find at least one honest node & report evidence immediately), A is now less secure since the slashing penalties for lying to A are lower

rige
But it’s not the light clients that should be performing the slashing? not sure I follow
hmm okay - As the bonded supply goes up the security of the network goes up, so as unbonding inflation is being added, the security of the network is constantly slightly decreasing, oh okay - so we want to hold this constant by increase the %slashability over the bonding period. Okay yeah - I guess that’s idealistically a bit nicer - a bit more confusing to explain though (edited)

cwgoes
No; the light clients are reporting the evidence to full nodes
Yes, that's what I mean

rige
So if we slash for the inflation reward too - we level the playing field for validators committing crimes against Security Model A and B?

cwgoes
That's the property I'm trying to get, yes (edited)

rige
👍 - okay I’m on board, I think it’s a good idea

cwgoes
what we really need (IMO) is a concrete PoS security model (edited)
exactly what guarantees we are trying to provide, under what "rational actor assumption" this system is secure, categorization of the ways in which particular fractions of stake could collude at particular times

---

@cwgoes commented on Fri Aug 17 2018

Tabled to post-launch by slashing design meeting.

---

@ragjunk commented on Mon Aug 20 2018

Quick question on how the slashing is enforced when > 1/3 of the validators act maliciously at the same time? This is the case when an outsider wants to take the network down by colluding with > 1/3 validators or somehow acquiring > 1/3 of the total stake. In this case, it is unlikely that individual bad actors act maliciously one at a time (in order to avoid getting caught), but may do so at a predetermined time. In this case, the BFT threshold is breached almost instantly. I am wondering how the slashing can be decided without some kind of voting just like the voting to approve the blocks. For example, the colluding nodes can arbitrarily decide to slash other honest nodes, if such voting mechanism is not instituted. I didn't see any spec on how the honest nodes as a whole decide and agree that one or more of malicious nodes must be punished. Any pointers or thinking on this is greatly appreciated.

---

@cwgoes commented on Tue Aug 21 2018

@ragjunk That sounds like a great question - but probably best suited to a different issue.

---

@jackzampolin commented on Fri Oct 12 2018

According to the slashing spec tracking issue this has been addressed. Closing.

---

@cwgoes commented on Fri Oct 12 2018

According to the slashing spec tracking issue this has been addressed. Closing.

It has not but is now post-launch.

---

@jackzampolin commented on Tue May 28 2019

I haven't heard any discussion about doing this. Going to close this issue.

---

@cwgoes commented on Tue May 28 2019

I haven't heard any discussion about doing this. Going to close this issue.

I think it's still worth considering. If we're going to close all the incentive-related issues can we port them somewhere?

I'm willing to do this if you like.

---

@jackzampolin commented on Tue May 28 2019

@cwgoes if you would like to port them to gaia that would be great. I think carrying on the discussion there is a better idea.

---

@cwgoes commented on Fri May 31 2019

@cwgoes if you would like to port them to gaia that would be great. I think carrying on the discussion there is a better idea.

That sounds fine - alas, I do not seem to have the permissions to move issues. Do you?

[alexanderbez]

Moved @cwgoes ⚡️

[tmckenzie51]

Hi @alexanderbez @cwgoes ! Based on what I understand from the thread in tendermint/tendermint#4581 (comment) , it seems as though TotalVotingPower was kept as a field in order to facilitate implementing this proposal. Is there still interest in this proposal or have there been any other developments? We'll close this issue in 1 week if we don't hear back. Of course, if interest arises again in the future we can always reopen.

[alexanderbez]

Oh gosh, this is a pretty old issue. Tbh I don't remember much of the context. Based on the convo in the tendermint/tendermint#4581 (comment), it seems like we do need that field. So I would open an Tendermint issue and PR to reintroduce it if there's consensus on it 👍

[cwgoes]

Honestly I still think this is an idea worth considering. Is anyone actively working on proof-of-stake at the moment? If so, I would route this issue to them and see what they think. If not, it can be closed I suppose.

[tmckenzie51]

Thanks for the input @alexanderbez. I've opened a new issue in Tendermint with these details.