At the end of the voting period I expect to have in SC:
vote[‘A’] = 10
vote[‘B’] = 30
vote[‘Z’] = 0
If I understand correctly, ECCs are used to hide the identity of users when they vote by having 2 third parties involved the voting agent and the vote counter. If I replace those 2 with 2 smart contract then how can I make the vote counter key private as everything is public in smart contracts. Is the solution to have it off chain ?
Also as an extra problem, what about if I want to allow voters to update their vote before the end of the voting period ? I suppose they should be able to pass an extra information like an ID with their vote but then it needs to use an algorithm that could not create collisions.
Votes are private except to the trusted coordinator, who cannot tamper with results. Results are tallied off-chain and proven to be valid on-chain via ZKPs. Voters can update their votes before the end of the voting period, and they can even submit invalid votes, which is part of its anti-collusion mechanism.
Further privacy can be achieved with Elgamal rerandomisation described here. This would prevent the coordinator from learning how any user voted.
Votes are private except to the trusted coordinator, who cannot tamper with results. Results are tallied off-chain and proven to be valid on-chain via ZKPs
I’m trying to find if there is a way to keep everything on-chain. Is the coordinator off-chain to keep its private its private key which couldn’t be done if in a smart contract ?
Also, can it work with something else than a vote ? let’s say a message where information could be extracted from (let’s say they could vote for multiple people with an order of preference, it could be somehow converted to a string or an integer).
Voters can update their votes before the end of the voting period, and they can even submit invalid votes
I really like that ! And great link to prevent the coordinator from learning anything about the votes.
The coordinator generates proofs of correct message processing and vote tallying off-chain. These proofs are then verified on-chain. The coordinator has a special private key (in the BabyJub EdDSA format) which allows them to decrypt the votes and generate the proofs.
MACI currently supports the quadratic voting use case, but modifications to support other use cases or voting formats are possible. A new vote tallying circuit would have to be written, for instance.