The 34% cabal & selective precommit censorship

[cwgoes]

I think we need to be very careful about the combination of slashing-for-downtime and proposers controlling inclusion of precommits (which determines downtime) in blocks.

Consider a 34% stake cabal. 34% of stake can halt the chain, but not single-handedly sign blocks. However, they can also selectively censor, only (say) voting for blocks they propose, and controlling which precommits they include in those blocks. The cabal must include at least 1/3 of the stake in each block to keep making progress, but they can choose a different 1/3 to include each block (alternating between halves of the remaining stake not in the cabal).

If they do so, alternating which half of precommits to include each block, after the SignedBlocksWindow has passed, all of the remaining validators will be slashed and removed from the validator set because they will have just passed the missed blocks threshold (which is set at half the window presently) - then this (former) 34% will now comprise 100% of the bonded stake and have complete control over the chain.

Increasing the threshold (permitted number of blocks missed) prevents this attack, but may be undesirable becuase it allows validators to be offline more than half the time they're supposed to be validating. I'm not sure what the right solution here is - ideas welcome!

cc @ValarDragon @sunnya97

[ValarDragon]

Great point thanks for writing this up! Note that any SignedBlocksThreshold is susceptible to this attack. (You slash one small subset of validators at a time, incrementally increasing your proportion of stake until you get 2/3rds) Albeit, lower signing thresholds take longer to execute and thereby are more likely to be observed. We should absolutely make tooling to detect this happening on a relatively small timescale as compared to signed blocks window.

Note that the goal of downtime slashing is to provide an incentive for validators to remain online. I think this incentive could in stead come from fee rewards. We could just have fee rewards only go to validators who signed on the block. In the fee distribution model I discussed briefly yesterday, this can be done at 0 additional cost. Then we can do away with liveness slashing. If stake goes offline then, it isn't immediately increasing the cabal's relative stake proportion all at once. Instead everyone else is gradually gaining stake via inflation. The delegators will presumely delegate away from the offline validator, so maybe this point is moot, as that may be getting evenly distributed amongst everyone else. (Note that the cabal has no direct control of who goes offline here, or who they end up delegating to though)

I do think we should prioritize coming up with a concrete security model for our system. We have the properties that f stake can halt, and 2f can fork, but we should define exactly what properties we want in attackers between these two points. At minimum I believe that we should aim to minimize the rate at which an f + 1 attacker can become 2f via exploits, and make all such attacks as observable as we can.

[cwgoes]

Now that we have F1 merged, I think we can address the underlying problem here by incentivizing uptime at the most granular level of individual signatures as opposed to averaged downtime, and increasing the jail-for-downtime threshold so that a 34% cabal cannot alternate-censor-precommits as described above.

This requires the following changes:

• Alter the reward distribution function so that validators only receive rewards if they actually signed the block.
• Remove slashing-for-downtime, and instead jail (using the existing counting mechanism) at a much higher threshold - maybe 800 / 1000 or 900 / 1000 blocks.
• Ensure that BonusProposerReward is high enough that the proposer is better off including precommits than censoring them.

[alexanderbez]

This is great @cwgoes. Is there not directly a way to incentive and rewards proposers proportional to the number of votes/pre-commits they include? Or is that covered?

[cwgoes]

Is there not directly a way to incentive and rewards proposers proportional to the number of votes/pre-commits they include?

This is the BonusProposerReward.

[cwgoes]

Is there not directly a way to incentive and rewards proposers proportional to the number of votes/pre-commits they include?

This is the BonusProposerReward.

This is simpler than I thought - we simply pay the proposer rewards proportional to the fraction of precommits included, subtract the community tax, and split the remaining reward for block signers among all validators who signed the block proportional to their stake - it will always be in the proposer's incentive to include signatures since failing to do so doesn't alter the rewards other validators receive (and always causes the proposer to receive less), just which validators receive it.