Grant proposal: An anonymous identity and voting system

🪻 Nym Squad League Proposals
1

General

ZK Voto Digital is an on-chain voting system that allows citizens to cast votes for custom proposals using government provided credentials while staying anonymous by using Zero Knowledge-proofs to prove their identity and humanity

The project aims to develop a zero-knowledge proof infrastructure solution for enhancing digital identity systems, starting with Costa Rica. Our goal is to strengthen citizen privacy by minimizing data collection, enabling individuals to access a wide range of valuable services without disclosing sensitive information.

We already have developed an initial Proof-of-concept you can find here: zk-firma-digital and here zk-voto-digital. The project is Open Source under the Apache-2.0 license. Currently we want to show the capabilities of our approach by allowing Costa Rican citizens to participate in voting proposals in an anonymous way while keeping the ability to authenticate with their digital identities and therefore proving that they are humans (no bots), and also are enabled to vote, all by using blockchain technologies. For this we use Circom and the Polygon Blockchain network.

However, the project still has a significant flaw. An adversary with broad network monitoring capabilities may determine the source of a vote (Or the user creating a ZK identity), such as the IP address, and therefore de-anonymize the person behind a vote. We want to add the Nym network’s anonymization capabilities to solve this problem.

Problem it Solves

Our project aims to address privacy issues in government identification systems, such as Costa Rica, by developing a zero-knowledge proof infrastructure. This solution enables users to verify their identity and provide specific information without revealing personal details. We can significantly reduce the risk of data theft by minimizing the distribution of sensitive data across various institutions and companies. Additionally, this system can authenticate users for diverse services, ensuring they are real individuals and not bots, without requiring sensitive information such as email addresses, phone numbers or biometric data.

Our current proof of concept does not include network-level anonymization. An adversary able to see the users’ traffic could determine the identity of a person by analyzing the transactions traffic and the actual vote on-chain. This de-anonymization could lead to problems such as voter corruption, collusion, or even blackmailing, destroying the purpose of the privacy-preserving system.

The Nym network provides a suitable solution to this problem, by mixing the traffic of the users using ZK Voto Digital and covering the flaw the current project has that the used Zero Knowledge technology does not solve.

Developers

  • Team Members:

Andres Gomez (Costa Rica) - Ph.D. in cybersecurity from the University of Frankfurt and CERN.

Francis Gomez (Colombia) - Specialist in project management and computer scientist.

Plan

Milestone 1 — Allow users to participate in voting proposals with network-level anonymity

Estimated Duration: 4 weeks

  • Research how we can use the Nym SDK (Typescript).
  • Allow the current web app to read the smart contract using the Mixnet.
  • Implement ZK identity creation with hidden traffic.
  • Allow the user to send transactions (e.g. cast a vote).
  • Allow users to check vote proposal results anonymously.

Milestone 2 — Release and gather feedback from the community

Estimated Duration: 4 weeks

  • Release alpha version.
  • Advertise the solution among the community.
  • Gather feedback.
  • Improve based on feedback and debug.
  • Make the app flexible enough to allow other countries’ identities systems to benefit from this project (Example: Indian’s Anon Aadhaar or OpenPassport).

Costs

  • FTE (Full-Time Equivalent): 1 FTE.

These costs include 40 hours of work per week x 8 weeks x 32 USD per hour = 10,240 USD

TOTAL: $10,240 (~172,898 NYM)

Benefits for NYM

The project aligns closely with Nym’s mission and goals by offering a privacy preserving layer for government-based identity systems, such as the voting systems. It can be extended to many more use cases. This project will empower users to have a more private and trustworthy relationship with governments and private services that can benefit from anonymous digital identities and proof of humanity without compromising users’ sensitive data.

This project can showcase the use of Mixnet technology for novel applications such as digital identity, verifiable credentials, and proof of humanity. It will bring new community members worried about their online and on-chain privacy.

Future Development

We plan to extend the functionality of our proof-of-concept system to allow several use cases such as:

  • Anonymous proof of humanity
  • Health data privacy
  • Know Your Customer
  • Privacy-Preserving Verification
  • Anti-Sybil Mechanisms
  • DAO Governance
  • Quadratic Funding (QF)
  • Wallet Recovery
  • And more

Also we want to extend the usage of ID smart cards to other countries. For instance, the EU has similar kinds of IDs for their residents.

Thanks a lot for your questions and feedback!
kurono

7 Likes
2

We need it! Great proposal, @kurono!

1 Like
3

Thanks a lot @craftdome ! Looking forward for feedback or questions.

1 Like
4

Hi @kurono thanks for the proposal.

It would be cool to see an existing application get ‘mixnetified’ like this.

One point to make right now: we’re currently having a problem with the build process for the TS SDK which given the upcoming launch is going to unfortunately have to wait for a little while to get solved: this is not an insurmountable issue by any means, just more a heads up regarding timing.

I would be interested to know some info about the sort of traffic patterns / volumes the app currently sends, in order to work out the current viability for the TS SDK.

  • Do you have any ideas on the size of RPC (I presume) requests that are sent from the UI to the node infrastructure you use?

  • Does your UI expect concurrent requests to occur? Or is it a more single channel submit tx => receive response sort of pattern?

  • What in-browser wallet infrastructure / libraries are you currently using? Forwarding traffic from a browser extension (for instance) through the Mixnet is currently quite difficult due to the fact that the Nym Clients set up Websocket connections with Entry Gateways (the first hop into the Mixnet). We are currently R&D-ing a protocol change to remove this to make it easier for applications like this, but this is currently being prototyped, so again, just more of a timing point for your reference.

Happy to answer any questions you might have, and cool project!

1 Like
5

Hey @max-nym , thank you for your feedback! Here are my answers:

  • Do you have any ideas on the size of RPC (I presume) requests that are sent from the UI to the node infrastructure you use?

There are currently two main kind of transactions, one for creating a custom voting contract (bigger) and another for casting a vote (smaller).

  • Does your UI expect concurrent requests to occur? Or is it a more single channel submit tx => receive response sort of pattern? What in-browser wallet infrastructure / libraries are you currently using?

In general, the app uses a desktop app to generate a private identity and then such a identity is utilized by a web app to interact with the smart contracts. The web app uses the Metamask browser extension, but the idea is to make it usable from the phone as well. So, it would be more a single channel transaction/response pattern.

Then, I guess given the state of the Nym API/SDK the application would have to wait a bit to be able to be ‘mixnetified’ when using web and browser extension tech. Are there ways to work around this?

  • What if we use a custom RPC endpoint that does all the magic in the way Nym currently supports?
  • What if we completely use the desktop app for the on-chain interaction (Like a wallet?)
  • Would using the app from the phone give better implementations alternatives?

Thanks again

6

Thanks for the answers and sorry for my slow reply: the launch of the NymVPN took a lot of time in the last few weeks and I didn’t have time to write a proper response.

Then, I guess given the state of the Nym API/SDK the application would have to wait a bit to be able to be ‘mixnetified’ when using web and browser extension tech. Are there ways to work around this?

Regarding this, there’s a few things to keep in mind:

  • Our TS SDK needs a bit of a rework at the moment with the build, we need to redo that. But in general, if you’re signing something with Metamask, then we currently don’t have an integration with Metamask, which would pose a bit of an issue, since you’re having to essentially intercept the signed tx and then bundle it into the payload of the Sphinx packets being sent through the Mixnet, but because of the way that Metamask has constructed its security (a lot of code sandboxes) this is quite a pain to do / not trivial.
  • Furthermore, the connection between a mixnet client and the gateway is a websocket connection, and in general browsers don’t like making outgoing websocket connections. We’re working on some protocol changes to remove this which at least removes that difficulty.

What if we completely use the desktop app for the on-chain interaction (Like a wallet?)

This would help, if you were sending the traffic to an RPC endpoint that also had a Nym client sat in front of it, in able to provide a Nym address (Addressing System - Nym docs) to send the messages to. I would have a look at the TCPProxies in order to not have to rewrite your networking logic (TcpProxy Module - Nym docs), but you’d still have to have a think about how to intercept your signed tx, so you might have to split out the tx signing logic out from the sending logic.

1 Like