feat(slashing): lazily slash reluctant block proposers

[guidiaz]

Close #2543

[drcpu-github]

I guess the idea of this patch is that by increasing the replication factor, we'll eventually find a validator willing to propose a block and at that point we can enforce power slashing?

[drcpu-github]

A default replication factor of 12 is kind of high, no?

[guidiaz]

The higher the growing factor, the less probable that a big enough group of malicious stake entries can collude to temporarily censor the chain. For taking over up to 10 consecutive blocks, an attacker would need to keep at least 120 stake entries placed on the top ranking, simultaneously and during at least 10 epochs. Depending on the actual census, and whether multiple stake entries per validator address is enabled or not, this number could either be considered relatively high, or most probably (in the long run, if we expect census to grow in time), relatively low.

Nevertheless, the replication factor is proposed to be capped to some proportion of the total census. Two thirds has been initially proposed under this rationale: "if more than two thirds of census decide to censor the chain, the chain is to be censored".

In terms of P2P network traffic, one could argue that up to 2/3rds of eligible block proposers may potentially flood the network with competing block proposals, but not really:

• Nodes should only propagate received block candidates only if better than the best validated so far, and also if signed by a different validator.
• Eligible validators will only be able to propose one single block, no matter how many stake entries they have within the top ranking.

[drcpu-github]

I'm okay with the capping, but was thinking that it would be better to follow the same power law as with data request eligibility: 4 * 2 ** (epoch - prev_epoch - 1).

epoch	power	linear
1	4	12
2	8	24
3	16	36
4	32	48
5	64	60
6	128	72
7	256	84
8	512	96
9	1024	108
10	2048	120

In the end it's unlikely to really matter though, both for the ratio of blocks mined and actual liveness.

[guidiaz]

We did consider the idea of implementing an exponentially increasing replication factor for mining, but discarded it for two main reasons:

• Exponential increase opens the door to pass too quickly from a situation where all candidates in epoch N refrain from propsoing blocks, to a situation in epoch N+1 where half of eligible validators are prone to propose.
• Being realistic, and as long as we manage wit/2.0 to not foster "sock puppets" behaviours, we can expect the census to be in the order of hundreds or thousands.

I'm not fully bullish on going linear instead of exponential, though. We just don't have enough info and cannot forecast the future. If we were afraid of DoS attacks being kind of probable, even those lasting more than 10 epochs, yeah, going exponential could be a thing. Then again, I don't believe these attacks will be that easy, and tend to think that going exponential may introduce more instability than the one we pretend to avoid.

Btw, an improved witness eligibility and slashing mechanisms are about to be proposed. Spoiler alert: "witnesses should be randomly selected out from the first ranking tertile of the mining census".

[drcpu-github]

Yeah, the idea behind an exponential approach is obviously start smaller, ramp up quicker so we do not have 10 epochs of missing blocks due to an attack. I doubt we'll need this in any realistic scenario though.

Any attack longer than an epoch or two will be quite costly or even straight up impossible (taking into account the total circulating supply). If we assume a base factor of 12, you need to control the top 12 most powerful stake entries, which means you'd likely need to control 120M WIT as a start, 240M the epoch after it etc. The assumption here of course is that there will be honest actors with the maximum stake of 10M (but it would be quite a pity if that is not true).

[aesedepece]

That's my line of thinking too. When assessing the right replication factor RF, we need to take into account how credibly can an attacker take over the top RF positions in the rank. Under consideration of the economic criteria presented by @drcpu-github above, and based on what we've seen in the 4 years of mainnet, it is reasonable to think that 12 may be a bit too much for a start.

On the other hand, what's the downside of a high-ish initial RF value? Bloating the network with redundant messages doesn't sound specially of concern here, under the assumption that block candidates are still subject to comparison and filtering as they travel through the network.

As per the power vs. linear progression, I favor power because it has worked pretty decently so far, but don't oppose to linear if it is found to be more suitable for PoS.

[drcpu-github]

When assessing the right replication factor RF, we need to take into account how credibly can an attacker take over the top RF positions in the rank.

An RF of 4 seems somewhat likely that someone can suppress block production in the network for a single epoch as that only requires ~40M WIT. Doubling or quadrupling that for the second and third epoch (using a power progression) requirement seems like it would already require significant (capital) effort, but still possible. Anything higher seems quite unlikely given what we know about the coin distribution.

It is certainly true that a power progression starting off with a low base RF (e.g., 4) is more likely to lead to single or double epoch denial-of-blocks than a linear progression with a high base RF (e.g., 12). I guess we could make the base RF 8 (4 * 2 ** (epoch - previous_epoch)) as a middle ground if we choose power progression after all.

In the end, I'm pretty ambivalent to the final choice, it's just that I like powers-of-two more. 😉

On the other hand, what's the downside of a high-ish initial RF value?

A couple of things I can think of, but all are pretty unlikely:

1. If the ranking does not work entirely as expected on breaking ties, selecting more initial proposers could introduce some imbalance.
2. More valid block candidates in the network means a higher likelihood of partitioning under less-than-ideal network connections between peers.