From c41af0f227ad76ea518fde4f6a9a17cbec28ee2b Mon Sep 17 00:00:00 2001 From: ctrlc03 <93448202+ctrlc03@users.noreply.github.com> Date: Fri, 17 May 2024 11:22:19 +0100 Subject: [PATCH] docs(blog): add whats next for maci post --- website/blog/2024-05-17-whats-next.md | 68 +++++++++++++++++++++++++++ 1 file changed, 68 insertions(+) create mode 100644 website/blog/2024-05-17-whats-next.md diff --git a/website/blog/2024-05-17-whats-next.md b/website/blog/2024-05-17-whats-next.md new file mode 100644 index 0000000000..b45124097b --- /dev/null +++ b/website/blog/2024-05-17-whats-next.md @@ -0,0 +1,68 @@ +--- +slug: whats-next +title: What's next for MACI? +description: Dive into the next MACI protocol changes and improvements. +authors: + name: ctrlc03 + title: MACI dev + url: https://x.com/ctrlc03 + image_url: https://avatars.githubusercontent.com/u/93448202?v=4 +tags: [voting, security, anonymity] +--- + +Minimal Anti Collusion Infrastructure ([MACI](https://github.com/privacy-scaling-explorations/maci)) is a Public Good that allows one to run secure, private, on-chain voting polls. + +Given its open source nature, it is not uncommon to develop new features or to have to fix issues based on community feedback. However, something that does not usually happen is external contributors making changes to the core protocol. + +Well, this soon will be a reality thanks to a proposal sent by the [3327](https://3327.io/) team. 3327 is collective of 10+ people working on improving blockchain technologies, with a focus on research and engineering. + +This proposal can be divided into two parts. First of all, the idea is to bring unconditional privacy to MACI's voters. After which, the focus would shift to optimising inefficient merkle tree structure holding messages, by replacing it with a hash chain. + +## Provide unconditional voter privacy + +Currently with MACI, if a voter performs a [key change](https://maci.pse.dev/docs/key-change), the voter's new key would not be anonymous. The coordinator could collude with a bad actor to inform the latter of the key change, as the coordinator would have access to all decrypted messages. + +The key focus of this improvement would be to allow users to be completely anonymous by removing the link between the original signup key and the key used for voting. How would this work? Well, users sign up to vote via the [MACI contract](https://maci.pse.dev/docs/contracts#macisol), and depending on the gatekeeper in use, they'd have to prove that they've passed the entry condition. Now, given knowledge of this key, they can signup with a new key to polls deployed by this same MACI contract. + +Thus, they can prove anonymously that they know the preimage of a [`StateLeaf`](https://maci.pse.dev/docs/typedoc/domainobjs/classes/StateLeaf), by passing this information to a zk-SNARK circuit, and validating this proof within the poll contract when joining with the new key. Of course you might be thinking that everyone knows the preimage of a state leaf, as it's public information that can be taken from the contracts' logs. However, the circuit will not accept the public key directly but would instead take the private key and use it to generate the public key. This way, only users with knowledge of a specific private key can generate a valid inclusion proof. + +Now after signing up to the poll with this new key, there will not be any link to the original key, and users will effectively be anonymous. Of course users should ensure that they are using different wallets where possible. + +Finally, with the use of a nullifier, it will not be possible for the same original key to be used to signup more than once for each new poll. + +Are there any drawbacks? Well, yes. There is now an extra step for users to register to individual Polls. We aim to offset this cost and additional step soon either with gasless transactions or by moving some logic offchain. + +## Message structure optimisation + +On top of the improvements to anonymity, the 3327 team aims to also replace the Merkle Tree used for storing messages with a hash chain. Some of the benefits of this approach are: + +- unlimited number of messages +- removal of expensive merge operations from the coordinator +- cheaper to send messages as only one hash is required to update the hash chain +- less constraints on the circuits due to simplified logic + +**Unlimited messages** + +Merkle trees are usually bound by a depth property. Together with the number of leaves per node, we can calculate the max capacity of a tree. For instance, for a binary tree with a depth of 10, we can host up to **2^10** (1024) leaves. On the other hand, hash chains do not have a limit, unless if we wanted to set one, so we technically can support an unlimited number of messages. + +**Cheaper operations** + +In general, hashing the previous hash chain with the message is cheaper than inserting into a merkle tree, as well as the coordinator not needing to perform any merge operations on the accumulator queues that were used on chain, thus greatly reducing costs and processing time. + +**Smaller circuits** + +As cited in their proposal, processing message inclusion proofs for **k** messages in a tree with height **h** requires **k \* h** hashing operations within the circuit with **2 \* k \* h** signal values for inclusion proofs. Processing messages with chain hashes removes the unnecessary inclusion proofs and requires only **k** hashes to be computed for **k** messages without any extra signals, as the requirement is to prove that the order and inclusion of all messages are correct. + +## What does this mean for you, Anon? + +We encourage all community members to contribute as much as possible to the development of MACI! After all, our goal is to build the most secure e-voting system, and this cannot be accomplished without all of your support. + +As a team, we are incredibly excited about this proposal and will continue to work hard to help the team get this production ready in the next 3 months. + +To contribute to MACI, submit issues, or learn more about it, you can reach out to us either via [Discord](https://discord.com/invite/sF5CT5rzrR) or [GitHub issues](https://github.com/privacy-scaling-explorations/maci/issues/new/choose). + +If you have an idea you'd like to work on, reach out to talk to us and we could create a proposal to build together! If you don't have an idea but would like to work on MACI still, we have some research ideas which might inspire you and we could collaborate on a grant together! + +- [MACI coordinator in a TEE](https://github.com/privacy-scaling-explorations/maci/discussions/1385) +- [Group wise matching](https://github.com/privacy-scaling-explorations/maci/issues/905) +- [Folding schemes for MACI's circuits](https://github.com/privacy-scaling-explorations/maci/issues/904)