Improve parachain liveness by reducing required number of backing votes

[eskimor]

Second (node side) part of: #4386

Can be merged - Polkadot runtime has been upgraded already.

[rphmeier]

This does have security consequences in that it means fewer validators are on the hook and that effective backing group sizes of >3 are impractical. I wonder if we'd rather address this on the governance side by just setting group size to 3. Although 2-of-5 is less likely to fail than 2-of-3

[rphmeier]

Eventually, this should come with the ability for validators to provide backing statements after-the-fact so that they're not cut off from rewards by malicious block authors who omit their statements. That's already a problem, this just makes it slightly worse.

[eskimor]

This does have security consequences in that it means fewer validators are on the hook and that effective backing group sizes of >3 are impractical. I wonder if we'd rather address this on the governance side by just setting group size to 3. Although 2-of-5 is less likely to fail than 2-of-3

Exactly - for liveliness purposes a larger group, but lower threshold increases the likelihood of getting a candidate in. this is meant as an intermediate improvement, until we have async backing.

Eventually, this should come with the ability for validators to provide backing statements after-the-fact so that they're not cut off from rewards by malicious block authors who omit their statements. That's already a problem, this just makes it slightly worse.

It makes it worse in the sense, that now we will be able to successfully back with less votes. But without this, the candidate would not be backed at all in that case and no validator will get any reward - so it should be a net improvement.

If the additional vote comes on time, we will still include it as backing always keeps the provisioner up to date on received votes.

[rphmeier]

If the additional vote comes on time, we will still include it as backing always keeps the provisioner up to date on received votes.

Let's update our threat models, please - we are writing economic games more so than software. Incentives matter, and reward-points are zero-sum. Yes, our 'honest' node implementation does not discard votes. Validator operator groups will fork and update our code over the next years to grind out every possible profitable edge. This is also why the runtime is the source of truth.

[eskimor]

bot merge

[burdges]

At the theory level we do not yet know if this has any real optimization consequences elsewhere, but..

Intuitively I always worked with one validator being 100% slashed when playing around with the simulator that Jacob Lell extracted from Rob's code, so this should be fine.