You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In voting systems with off-chain vote storage, where casting a vote is typically free, some users may still refrain from trusting such a system.
For such users can one can implement ability to cast votes way to a L1 (Cardano).
If event is configured not to reveal results while voting is taking place, cast votes can be encrypted on L1, e.g. private and public encryption keys would be generated when event is created by vote-admin-tool and public key attached to the event registered on chain. Once event finishes, a private key could be revealed. That in turn would allow for any external parties to tally the votes from L1 submitted transaction data.
There is a trade off for this design. An implementation would simply cast 1 vote = 1 encrypted L1 transaction, in this case it wouldn't be possible to know which proposal is leading in which category but it would be possible to know via writing an L1 indexer how many votes in total have been cast using L1. Such a limitation / design trade-off maybe ok for some voting events, perhaps not for others.
Suggestion: whether votes should be encrypted on L1 should depend on event's configuration related to leaderboard / results showing / on and off while voting.
The text was updated successfully, but these errors were encountered:
In voting systems with off-chain vote storage, where casting a vote is typically free, some users may still refrain from trusting such a system.
For such users can one can implement ability to cast votes way to a L1 (Cardano).
If event is configured not to reveal results while voting is taking place, cast votes can be encrypted on L1, e.g. private and public encryption keys would be generated when event is created by vote-admin-tool and public key attached to the event registered on chain. Once event finishes, a private key could be revealed. That in turn would allow for any external parties to tally the votes from L1 submitted transaction data.
There is a trade off for this design. An implementation would simply cast 1 vote = 1 encrypted L1 transaction, in this case it wouldn't be possible to know which proposal is leading in which category but it would be possible to know via writing an L1 indexer how many votes in total have been cast using L1. Such a limitation / design trade-off maybe ok for some voting events, perhaps not for others.
Suggestion: whether votes should be encrypted on L1 should depend on event's configuration related to leaderboard / results showing / on and off while voting.
The text was updated successfully, but these errors were encountered: