Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Aragon Nest Proposal: Secret voting infrastructure using Ring/Threshold signatures #12
Aragon Nest Proposal: Secret voting infrastructure using Ring/Threshold signatures
The first Metropolis release, Byzantium, introduced a series of precompiled
These operations allow for great things such as verifying zkSNARKs proofs,
Ring signatures are a cryptographic construct that allow a number of keyholders
This technology could be used to implement secret voting on-chain with a flow similar
A smart contract implementation (plus off-chain tooling) to achieve:
As this project will require a significant research effort which will probably result in
We intend to make an Aragon app for secret voting using this tech in the first half of 2018.
For future readers interested in blockchain voting systems or otherwise any voting system using electronics: Any high stake voting system such as a nation election MUST be accompanied by a software independent audit trail to have any value. Specially if that voting system involves having devices connected to the internet.
I have been researching trustless voting systems as well and had a proposal that uses similar techniques to provide anonymity to this but is focused on large scale voting systems.
Please read this and tell me if it you think I should create a new issue. Suggestions are also welcome.
Vīsus : High Throughput Decentralized Voting System
Many of the current on-chain voting systems provide elegant solutions with features that traditional (client-server) e-voting couldn't deliver. However, most of them are either too expensive or too slow to implement on public chains when high throughput is required. Consortium chains can provide such scalability but require users to trust that authorities won't fork the chain. This restricts trustless voting systems to be used on the main chain by small groups and prevents usage in large scale voting systems such as the ones used to elect presidents and state representatives.
By leveraging security of the Ethereum mainnet and performance of a tindermint child chain it is possible to offload high throughput requirements from the main chain while retaining guarantee that tokens can be withdrawn to the main chain even if the child chain completely halts. By submitting merkle roots of every 2^n blocks we can trade finality to further decrease the cost of maintaining the child chain.
Note: PoC will be UTXO based to simplify proof verification on the parent chain.
**Note: The tokens stay on the candidates' wallets forever, are considered spent and cannot be withdrawn to the parent chain again. The tokens received by block producers are newly minted tokens from coinbase transactions.
Block producers, validators and stakers will receive tokens proportional to the number of tokens processed in a block such that blocks with 0 transactions provide no reward.
For these plans we must keep in mind that a voting system has requirements that most plasma chains don't need to deal with:
If voters loose their private keys they can recover them using uPort's social recovery.
referenced this issue
May 23, 2018
There is an interesting related discussion started by @evainfeld at ZcashFoundation/GrantProposals-2018Q2#22 (comment)
I think most threshold classic signature schemes do not do what you want here:
It's true they provide a measure of anonymity, but the anonymity set is tiny due to the communications cost to set them up. Also, threshold signatures do not provide anonymity from everyone, since someone must actually do the Lagrange interpolation.
You want a threshold signatures when (1) your participant set is tiny, and either (2a) you need to hide that a signature is threshold from non-participants or else (2b) you have higher bureaucratic cost for adding a new signature scheme than developer or protocol costs for managing the setup, i.e. you are bitcoin.
There should be deterministic ring signatures with which you can use simpler vote counting schemes, but actually there is a rich field around voting counting and better schemes exist.
@mariapao There is a problem with that proposal: child chains used for high stake voting systems MUST have high liveliness guarantees or would otherwise require significant coordination mid-voting session in case of an attack, so a plasma chain might not be the best solution for this kind of application.
Right now I am looking into swarm's mutable resource updates as a solution, so I won't apply for this proposal.
Thanks for the response