Calculating the genesis slashing penalty

[arjunhassard]

I'd like to open a discussion on this crucial component of the slashing protocol, and indeed our overall economic design. Our current logic and parameters originate from back-of-the-envelope reasoning in the nucryptoeconomics compilation doc:

penalty = basePenalty.add(penaltyHistoryCoefficient.mul(penaltyHistory[_miner]));
penalty = Math.min(penalty, _minerValue.div(percentagePenaltyCoefficient));

&

BASE_PENALTY = 100
PENALTY_HISTORY_COEFFICIENT = 10
PERCENTAGE_PENALTY_COEFFICIENT = 8

(see PR nucypher/nucypher#507 for more context )

Background

In general, it's not straightforward to design penalty calculation algorithms (i.e. determining the amount X to decrease a stake Y by, given offence Z), that yields fair punishments uniformly across all Y and Z, and maximises the likelihood of behaviour aligned with the protocol's goals. It's hence unsurprising that there's some variance in the approaches taken by prominent staking+slashing networks. For example:

Livepeer:

if (del.bondedAmount > 0) {
    uint256 penalty = MathUtils.percOf(delegators[_transcoder].bondedAmount, _slashAmount);
    del.bondedAmount = del.bondedAmount.sub(penalty);
... }

where the _slashamount coefficient depends on the offence (failed verification, missed verification, double claiming a segment).

Casper:

fraction_to_slash: decimal = convert(convert(recently_slashed * self.SLASH_FRACTION_MULTIPLIER, "int128"), "decimal") / \ convert(convert(self.validators[validator_index].total_deposits_at_logout, "int128"), "decimal")

where self.SLASH_FRACTION_MULTIPLIER = 3.

Polkadot's most recent testnet version:

Slashing starts with a 0.001 DOTs penalty and doubles. If your node successfully passes a session, the current penalty is reduced by 50% with a minimum of 0.001 DOTs.

And if this post is accurate, then a Tezos baker who screws up will immediately lose their entire deposit, including what they would have earned from the 'offending operation'.

Discussion

Penalties calculated with absolute figures (e.g. a fixed number of tokens) run into issues:

• Volatile token conversion rate to fiat means punishment in real terms has an unpredictable multiplier
• Fixed penalties can be overly punitive to small stake holders and potentially irrelevant to large stake holders. Making them large enough to be disincentivizing to large stake holders might wipe out smaller stake holders for a single error.

However, calculations involving the percentage of the offenders' stakes are also problematic:

• They can be overly punitive to large stake holders. For example, a set 10% decrease in stake for 2 nodes who commit the same offence/error, but node A holds $100k worth of tokens and node B $1k – larger node could reasonably consider it unfair that there's a $9,900 difference in absolute terms between their respective penalties. This could lead to a disproportionate favouring of smaller stakes, depending on each individual's perceived risk that they might commit a slashable offence. This is especially important if the network ever ventures into attributing offences imperfectly, or punishes offences that could be caused by network issues or censorship (i.e. nodes failing to come online)
• Traditional crime and punishment does not generally take into account the perpetrator's wealth, as percentage based penalties do (in the sense that theoretically the letter of the law treats, or should treat, everyone the same. Of course in practice wealthier citizens have many advantages with respect to criminal justice requirements such as bail / counsel costs).

Combination ideas

A natural solution to balance the tension between absolute and percentage based penalties is to combine them.
Broad ideas:

• Fixed amount OR Percentage of stake, whichever is lower
  more or less what we have now
• Fixed amount OR Percentage of stake, whichever is greater
• Fixed amount AND Percentage of stake
  More complex ideas:
• Percentage of stake input to penalty calculation modified by the size of stake relative to others.
  i.e. a tiered system wherein the greater the percentage of the total staked tokens you control, the smaller the percentage of your stake slashed given offence Z.
  Although this sounds slightly unpalatable, it would avoid large nodes abandoning the network when they are punished too severely (in absolute terms).
• Fixed amount figure calculated using current fiat value of tokens
  i.e. using a price oracle to calculate a base punishment – e.g. minimum of $500 fine for offence Z
  this would avoid uneven real-world severity of punishment due to token volatility

Choosing the exact parameters

e.g. 5% of stake if stake < 0.01% of network + fixed penalty of $100 in nu tokens
This is a to-do following a discussion of the approach. Also I think this will require scenario modelling.

[derekpierre]

Thanks for initiating this Arj.

Quick Thought:
I don't necessarily think that the percentage calculation is as "unfair" as it seems on the surface.

Something to keep in mind is that larger stakers receive more work from the network (and rewards) and are therefore relied upon more for the functioning of the network. Therefore, if they are dishonest it may necessitate a harsher slashing punishment than smaller stakers.

• In the context of your court example it could go the other way where wealthier citizens could receive more punitive bail judgements (higher amounts, loss of passport, or remand) because of their significant means.

The point is basically: in some cases equitable != equal.

That being said, I understand the point of adjusting the calculation since on its own is probably not the best solution.

Need to think a bit more about this.

[tuxxy]

I also agree with @derekpierre wrt percentage calculations not being "unfair".

Keep in mind that providing an incorrect re-encryption is pretty much the worst offense a staker can commit. In the example you give of 10%, I could even see this being too low.

Outside faults of our code, for someone to perform an incorrect re-encryption it would mean that they went through the process of modifying the code to do something malicious. It doesn't matter how much they staked, they have now become a significant threat to the network.

Slashing, therefore, has two predominant objectives:

1. Disincentivize stakers from acting maliciously via incorrect re-encryptions, and;
2. Remove malicious stakers from the network. (The most important one, imho.)

The second point above is the most important for our network's health. The slashing protocol acts as a recovery measure against fault. If a staker is willing to try to perform incorrect re-encryptions, they should not be staking in the first place. This isn't an act against a mistake (like downtime could be), but a penalty against a deliberate and malicious action.

[jMyles]

It seems that we need to consider the possible underlying causes of Ursula returning an incorrect CFrag.

• The most obvious one is that she's fucking with Bob. That's a paddlin' for sure.

• Maybe we pushed a bad update and she applied it. Then we're the assholes.

• Maybe she got infected with malware. Still her fault, but not as bad in terms of intent (though, as @tuxxy points out, it's probably not in our users' best interest for us to try to parse that).

• Maybe underlying OS updates caused some weird incompatibility that nobody had considered, but that we can easily and instantly fix with a patch. What then?

[cygnusv]

It seems that we need to consider the possible underlying causes of Ursula returning an incorrect CFrag.

Let's not forget 3rd party dependencies. We're not pinning the underlying cryptographic libraries (umbral, cryptography.io, OpenSSL), so we cannot rule out that an update there can cause some problem.

[tuxxy]

It seems that we need to consider the possible underlying causes of Ursula returning an incorrect CFrag.

Let's not forget 3rd party dependencies. We're not pinning the underlying cryptographic libraries (umbral, cryptography.io, OpenSSL), so we cannot rule out that an update there can cause some problem.

This is true, however, if we deploy code that has such an obvious problem, then it's our fault in general. Hopefully something like this would be caught in CI.

It doesn't really make sense for us to try to include every case where a proof can be faulty. That's not our role here. As we're building an autonomous, decentralized network it must have the partiality to decide for itself what the punishment is.

We cannot determine a "soft" penalty over a "hard" penalty. There is simply no way for us to do that.

If a group of stakers get slashed because of a bug in proofs or a dependency, it's up to the network to choose how to correct and my recommendation would be hard-fork.

[cygnusv]

You're right, such situation justifies a hard fork.
I'm not very concerned with the rest of situations that @jMyles describe, btw.

[tuxxy]

@cygnusv You make a great point that observes some flaws in our testing, though.

We should probably include property-based tests for all of our proofs to verify that they can't be faulty and include as many weird edge cases as possible.

[michwill]

I think, the "hard" punishment is indeed appropriate here.
We will need to go back to this question though once we start thinking about slashing for inactivity. A "soft" variant could be tied to the fee of creating a policy, or maybe total coin supply divided by total number of policies

[tuxxy]

In the form of "soft" punishment, I think a non-slashing penalty is appropriate. For example, (and this assumes we solve the downtime problem) if we identify a node who is down, we can just prevent them from receiving more KFrags and freeze their rewards until they come back online.

[michwill]

Yeah, and mark the whole time from the last check like that as "inactive". That works.