Client side

Stub

This describes possible ways of inputting the required information into MPC. There are various tradeoffs available. We will need to choose one at some point, but currently are uncertain on this.

Client, of course, needs to provide an aforementioned proof of validity of the vote. But this vote also needs to be encrypted in some way. This way, ideally, should be

1. MPC-friendly in a sense that it is easy to decrypt.
2. Proof-friendly in a sense the witness of decryption is easy to produce in MPC.

Separate parties handoff

This is the simplest way to implement, and, arguably, it also incurs minimal computation for MPC. It, however, leads to a $n$-times blowup in both bandwidth and client-side work.

This works as follows - the user creates their shares client-side, and encrypts them separately with public keys of the parties using some SNARK-friendly way (say, elliptic ElGamal over the JubJub curve + MiMC). They publish the encrypted shares. The MPC side then produces the proof of decryption (which is easy to do because the parts of the witness can be constructed by the individual parties).

Shared private key

In this case, the client encrypts the vote only once, and MPC does the proof of the decryption. It is less efficient in terms of the MPC work, but can be improved a bit by using different circuit for El Gamal decryption - doing $n$ separate scalar products with shares of the private key. This admits an efficient witness, because the scalar multiplication part of the witness is now held by the parties separately.

Outsourcing KZG input

This version is ideal from the MPC standpoint, but puts a very heavy computational load on the client.

In this case, the client does 2 transactions for each vote. First one is "register", which sets an id of the vote, which we will denote as $i$, and we will now assume that the vote structure has the length of $k$ field elements. Increase it by $1$, by adding the blinding factor vote.advice.

The second one consists of the encryption of the vote (in some MPC-friendly way), the proof of validity, and the following additional data:

1. The KZG commitment $\underset{t=0}{\overset{k-1}\sum} \text{vote.i }* L_{ki+t} + \text{vote.advice }*T$.
2. The proof that this KZG commitment corresponds to the decryption of the encrypted vote.

This, of course, allows to circumvent all of the proving work on the MPC side - it can just add up KZG commitments, creating the input column to the PlonK. The proof on the client side, on the other hand, is extremely heavy because it requires multi-scalar multiplication over non-native field. It remains to be seen whether it is possible to somehow tackle this issue.