election-provider-multi-phase: Add extrinsic to challenge signed submissions

[emostov]

The election provider multi phase pallet allows "staking miners" to submit elections solutions during the signed phase. We only store a limited number of solutions. There are a few areas here where a malicious actor can grieve the system:

• Due to the current storage layout, for any given solution score, only one solution can exist, which is problematic if miners converge on the same score since an attacker can block virtually all honest miners simply pre-crafting that score and submitting it with a bogus solution. This means the cost of ensuring no signed submissions works is just the deposit of a single solution as opposed to the cost of a queues worth of deposits.
• Currently we check the best solution, and if its ok we don't check the remaining solutions, meaning an attacker could spam the queue with no repercussion.

To address this we should add a challenge extrinsic. This extrinsic would take a solution id, check if the challenger has some min slash-able amount and then perform the costly operation of checking if the solution matches its claimed score.

• If the claimed score is correct, the challenger would be slashed. One optimization here would be to mark the solution as checked, so when we call elect we don't need to check the solution again.
• If the claimed score is not correct, the malicious submitter will lose the deposit, the solution will be ejected and the challenger will receive some reward. Importantly, the reward for the challenger must be less than the solutions deposit in order to ensure there is no incentive to submit a bogus solution and then challenge yourself.

Also note: /~https://github.com/paritytech/srlabs_findings/issues/97#issuecomment-1069218413

[Doordashcon]

Hi @emostov, i've been going through the code and would like to take on this issue :)

[emostov]

Sounds good - let me know if you have any questions

[Doordashcon]

"solution id" is synonymous to submission index and this index can be used to retrieve a signed submission?

[emostov]

Yes, it should be the submission index that is used as the key to this map:
pub type SignedSubmissionsMap<T: Config> = StorageMap<_, Twox64Concat, u32, SignedSubmissionOf<T>, OptionQuery>;.

This is guaranteed to be unique during the signed phase.

[kianenigma]

Due to the current storage layout, for any given solution score, only one solution can exist, which is problematic if miners converge on the same score since an attacker can block virtually all honest miners simply pre-crafting that score and submitting it with a bogus solution. This means the cost of ensuring no signed submissions works is just the deposit of a single solution as opposed to the cost of a queues worth of deposits.

FYI, this is no longer the case, as of paritytech/substrate#12237