provisioner: prioritize backing votes for disputes

[ordian]

See #6249 for the context.

With our slashing design centered around backers for both valid and invalid cases and in the light of #6249, we should always prioritize missing backing votes when selecting votes for a dispute set.

• Add a test in provisioner that we if there are missing backing votes on-chain, we always select them.

[eskimor]

@BradleyOlson64 This should be fairly simple as well.

[eskimor]

Not only prioritize, but make sure there are always imported - even if the chain already knows about some valid votes for those validators.

[BradleyOlson64]

The first issue I'm seeing is that we import votes to the provisioner from the disputes subsystem in an order that can't account for backing votes specifically. It only knows about which disputes to prioritize, not which votes to prioritize.

I think a solution might be to set up another call similar to request_votes called request_backing_votes. Not sure how easy it would be to support such a call from the dispute subsystem side, but without it I don't see how we could guarantee all unknown backing votes get into the dispute set.

[ordian]

Heads up: in #6249 I implemented the following logic

// We allow backing statements to be imported after
// explicit "for" vote, but not the other way around.

This makes it easier to implement slashing with our currrent design and should be fine considering

/// Backers should not participate in explicit voting so this only possible on malicious backers.

That means if we select a backing vote (if it's not present on chain already), we should not select an explicit "Valid" vote in the same set from the same validator.

It only knows about which disputes to prioritize, not which votes to prioritize.

My understanding is vote selection in provisioner (in the new version) happens in

polkadot/node/core/provisioner/src/disputes/prioritized_selection/mod.rs

Line 168 in b4b3fa5

async fn vote_selection<Sender>(

[ordian]

The issue was closed, but I don't see it being actually fixed or am I missing something (and the test is missing)?
If an attacker places an explicit "for" and "against" votes on chain (or just an explicit "for" vote), wouldn't its backing vote be filtered by the next honest block author?
Here

polkadot/node/core/provisioner/src/disputes/prioritized_selection/mod.rs

Line 200 in 6a5d31f

is_vote_worth_to_keep(

polkadot/node/core/provisioner/src/disputes/prioritized_selection/mod.rs

Lines 384 to 387 in 6a5d31f

	if in_validators_for && in_validators_against {
	// The validator has double voted and runtime knows about this. Ignore this vote.
	return false
	}

polkadot/node/core/provisioner/src/disputes/prioritized_selection/mod.rs

Line 396 in 6a5d31f

!in_validators_for && !in_validators_against

[ordian]

Another way to solve this problem is to ensure backers never participate in disputes in the first place as they shouldn't. But that requires the runtime being able to tell who's a backer easily, which might be harder to achieve.

[ordian]

As discussed on the call, we can get away with this problem by not allowing importing disputes votes without backing threshold backing votes. We already check it's non-empty in #6249, but we can also check for a threshold.

[ordian]

We already check it's non-empty in #6249, but we can also check for a threshold.

Actually, checking for a minimum_backing_votes is a bit tricky. We'd need to know the validator group size, which is not readily available in the disputes context.

It would still be nice for the provisioner to include the remaining backing votes even if explicit "for" votes has been placed on chain, so we can slash as many backers as possible. Provisioner has the information about kinds of valid votes.

[eskimor]

Yes, let's modify the filtering in the provisioner to never filter backing votes, even if the chain knows about them.

[eskimor]

@BradleyOlson64 We do indeed filter votes and not only full disputes here. We need to modify this to never filter backing votes, even if the chain knows about valid votes for that validator.

[BradleyOlson64]

This should do the trick #6494