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!

2 Likes
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
7

Hey @max-nym thanks about the answer and no problem, I am aware of the bad timing.

So It sounds like it would be wiser to first propose to create a wallet that can send transactions using the Nym network and later we can user such a wallet to many other use cases. What do you think? Maybe should I create a separate proposal for that?

8

Hey @sudonym any thoughts about this proposal? May this be included inside some Nym Squad League mission?

thanks

1 Like
9

@kurono this was sat in my drafts, so sorry! :man_facepalming:

I think with regards to the creation of a wallet, you can probably piggy-back on the signing functionality of an existing wallet to grab the signing functionality and then use the Mixnet client / SDK as the transport, There is some existing example stuff in the TS SDK, which I’m aiming to get working again soon (Cosmos Kit - Nym docs) which Cosmos Kit.

Right now we’re working on a protocol upgrade which might lead to some interface changes, but starting to plan out something like a generic wallet library would be interesting, looking at architecture and e.g. which crypto primitives to support.

1 Like
10

Hey @max-nym, thanks for your answer! So given the discussion we had so far we could change the Milestone 1 like this:

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

Estimated Duration: 4 weeks

  • Research how can the desktop app use a custom (existing?) wallet to communicate with the Nym network.
  • Allow the desktop 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) using the Mixnet client / SDK as the transport.
  • If necessary set up a custom RPC node to receibe anonymous transactions and forward them to the blockchain (Polygon) network.
  • Allow users to check vote proposal results anonymously.

Please let me know what you think, and if it improves the options to obtain the grant. Thanks

11
  • If necessary set up a custom RPC node to receibe anonymous transactions and forward them to the blockchain (Polygon) network.

It would be necessary to have some sort of client fronting the RPC node you wanted to communicate with via the Mixnet, yeah, which would basically involve:

  • a nym client, probably via the rust sdk
  • some sort of logic implementing message ordering and passing

Which is basically what is implemented in the TcpProxyServer ( TcpProxy Module - Nym docs ).

Otherwise this plan looks good to me - it would be cool to have the wallet specifics swap-in further down the line to make it feature-based (e.g. support multiple tx creation and signing types)!

1 Like
12

Oh thanks a lot @max-nym , I have taken a look of the documentation and now I got what you mean. Then the milestone would be like this:

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

Estimated Duration: 4 weeks

  • Research how can the desktop app use a custom (existing?) wallet to communicate with the Nym network.
  • Set up a Nym client for the local Wallet and another one for the remote RPC node using the TcpProxyServer to send anonymous transactions and forward them to the blockchain (Polygon) network, in addition to getting back the results and errors of the transactions.
  • Allow the desktop 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) using the Mixnet client / SDK as the transport.
  • Allow users to check vote proposal results anonymously.

This is not entirely clear to me, you mean, should I give more details about what would be the features of the wallet and what kind of transaction can it process?

13

Hey @max-nym , any comments on this?

14

That looks good. Bear in mind that the TcpProxy modules need to be on both sides of the Mixnet - which would mean either running the Rust code in your desktop app, or reproducing the message types + concurrency logic in Typescript. The problem there aside from the extra dev work is that the Typescript SDK is current a broken and we haven’t got a lot of resources to fix it, so I’m not sure when that might be possible.

Are either of these things blockers for you?

1 Like
15

Hey @max-nym , actually our desktop app is made mostly on Python so we could take a look of how nymCHAT is integrated with Rust to make our proposal work, no need to use the the Typescript SDK.

16

Ah then that works far more easily. Yes @code-zm made some Python bindings for their app - looping them in here :slight_smile:

1 Like
17

Great @max-nym ! Looking forward to work on this project.

1 Like
18

Just one quick thing: I just put a notice on the SDK documentation, but thought I would make sure you were aware in this post also.

We are in the planning stages of making some pretty big changes to the Rust SDK and its modules - I am hoping to get these changes in effect over the summer. These changes will coincide with some protocol level changes as well. As such, the RustSDK interface will most likely change quite a bit.

To stop you having to rework something you might have just finished writing the first time, I would suggest that you could try out an initial Proof of Concept of your idea with the TcpProxy code - there are also standalone binaries here for just pointing your app and server processes @ local sockets initially - but maybe wait a little while to start working on anything more. Just to avoid doubled work!

2 Likes
19

We will have more info about these changes public soon, including a roadmap and a signup for email updates

1 Like
20

Hey @max-nym , I was able to use the Nym proxy server in combination with the python web3 library, to connect to a Ethereum endpoint. I ran this:


./nym-proxy-server -u rpc-amoy.polygon.technology:443

./nym-proxy-client --server-address 

python main.py

And I got this:

python main.py                                                       
Current Amoy block number:
22995383
Connected to the Polygon Amoy testing network
Constracts loaded...

I uploaded the PoC code I have developed here:

So I guess from there I could extend the functionality to allow other interactions, such as voting anonymously.