Allow election coordinator to reset the finalization phase about concordium-governance-committee-voting HOT 3 CLOSED

The guardians don't need to recompute and re-register their decryption. But they would need to restart the ZKP generation part. I will go over the steps here.

1. Computer and register the partial decryption M_i
2. Start the ZKP by choosing some randomness and registering two values a_i and b_i

At this point we need to check how many guardians are present, and we continue with that set U. This should be uniquely defined, so that all guardians continue with the same set U.

3. We continue with the ZKP which involves computing an M, a, b from M_i, a_i, b_i for i \in U, generating challenges, registering the responses to challenges v_i.
4. We check the responses v_i from all guardians. If they are all good, we are done. The coordinator can generate the final result and the final ZKP from all the information present. However, if some v_i for i \in U is wrong or missing, then we need to restart from step 2. above, i.e., generate new randomness to start a new ZKP, choose the new set U' where the faulty guardians are removed, and finish the ZKP with this new set of guardians U'.

Note that guardians who weren't online in the first attempt at generating the ZKP could be used in the second attempt. Only if someone posts a v_i that is wrong should they be definitely excluded. But maybe it is simpler to choose U' as a strict subset of U.

from concordium-governance-committee-voting.

Makes sense. With regards to 1 and 2, the reason why I say recompute and re-register the decryptions is that the decryption shares and associated commitment shares for the proof are registered together, so while they might be two separate "things", they are always coupled in our implementation. But thanks for clarifying.

With regards to the issue of excluding guardians from the subsequent run of the decryption I don't think it will make it simpler to choose a strict subset of U for U'. I imagine the coordinator being able to mark a guardian as "excluded from future selection" if the challenge responses for that particular guardian are invalid (i.e. registered but invalid).

In the rerun of the generation and registration of proof commitments, we would then take this exclusion into account, both at the point of registration in the contract and the tools reading the contract (i.e. coordinator tool and guardian app).

Does this proposal make sense?
@abizjak @chportma

from concordium-governance-committee-voting.

Yes, it makes sense. I guess that if someone doesn't post a v_i, then they should also be excluded from the next attempt. Because if we include everyone in U' who posted a a_i and b_i in the next attempt, then a guardian could prevent us from ever finishing the ZKP by always posting a_i and b_i, but never v_i.

from concordium-governance-committee-voting.