Tools for Anon Communal Actions | Ryan and Violet, Open Source Contributor | ETHTaipei 2025

[Music] Hi everyone. Um so my partner Vile couldn't make this talk. Um so we so I'm going to um talk about what we work on during the uh privacy residency uh last month. We're working on a tools for a non-communo actions with zk for vote privacy and te for arbitrary threshold voting and registration foes and we're going to talk about um why we want to work on this and how the system has been designed and what we learned during implementing this and what are the current status of the system. So um if you're based in Taiwan um I think you guys will be familiar about that last year is a critical era of the workplace abuse situation in Taiwan.

There's several um or I'll say a lot like workplace abuse incident report um through public sector and also private company like there's a workplace abuse at ministry of labor which is quite interesting. Um but and there's also the workplace abuse at Delta Electronic and there's a recent instant at Cubo AI um that people might be familiar with locally and there's also um sexual abuse in um McDonald's in Taiwan. So last year is a uh kind of shocking year to me that a lot of things happened um make me realize that there's not a um communication way to talk about things that we want to talk about privately. So that got us interested and motivated into building this kind of solution for people. And during the privacy residency, we talked to several other resident uh throughout the month um with privacy researcher talk about the current reporting projects often lead to targeting on marginalized groups that um people will be get punished, get um harassed for starting to talk about something um publicly that might compromise other people's benefits.

And we talked to Amazon labor organizers um that the people who launches strikes on Amazon uh drivers will get punished and we talked to labor advocate um that the current tech problems really can build trust um cuz they are not uh privacy enough to make uh everyone trust the system to report or vote on something. Um and so we have a lot of shared experience inside the privacy residency that um people often are the advocates uh activists that do strikes that unite people and fight against something and these are usually the people that get punished and get picked on um when something went down. So instead of surveillance, we want to focus on positive collective actions to have a way to aggregate people's thoughts and to act together on something to have a group to have a support network. So the key design idea what we want to build is we want to have a solution that validated workers or other qualified people to join the system and we want them to have the ability to vote privately and then we want to aggregate all these signal all these vote from them and release the information once the threshold is met so that they can act together on this and so the design that we go is that user has a cryptographically or socially verified reservation foe. um what I'm going to talk about like what does it actually mean by cryptography and how do we verify and then once they join the system they'll have using zero knowledge proof to vote on specific topic and we'll collect all those vote privately together and once um the votes have a sufficient amount are met we will release all the vote that we gather from the user.

So some imagine use case that we talk uh during the residency is like lift driver strike because currently there's not a union for a lift driver. So they don't have a way to share information across each driver to understand what the working situation is like. So you want to provide a solution like this to them that they can collect and report things on um how much fee or how much money they're going to make on each ride and um is that fair? um are they exploited from the lift company? And um also bullying from bosses.

I think that's kind of obvious. Um we all have times that we want to report something about our boss and also the rent strike. Um like currently um the housing market is monopolied by um the landlord. We don't have a way to talk with each other like uh privately about what's the housing market is like, how much everyone is paying because no one wants to report this cuz once you report this you often get picked on by the landlord and often got punished. So this is also a use case that we can use ZKtos to provide the payment of the rent to the landlord and we colle and we can collect that data privately together and then have a aggregated information about how much everyone is paying are we being overcharged for the housing um rental price.

So that's a solution that um the anonymous coordination platform can provide and also um in general we can collectively um build a platform that migrate and protect data from the user. So this is how we built the system. We have four step or four uh component inside system. Uh the first one will be the identity and then registration, coordination and release. The identity identity part would be how we verify this user's identity and then once we um check that this person is allowed to join a certain group, we will register them into a certain group that they can use as a private or a pseudo anonymous identity to act on something.

Once we have that identity, we can let them um submit a vote, a proof on something they want to provide opinion on. And then that's where the coordination part comes in. And after we collect all the information, a certain threshold is met, um we're going to release the data together and signed by a trusted machine. about the identity part. Now we're using ZK email um to check that the person have a specific domain of email that's say a company.

So once we verify he she they hold the specific email then we can allow them to join the group um to act on providing opinion on that company and this um identity solution can be further expanded to different options uh cryptography actions like using NFC chip like uh we came up with this idea because um the Amazon driver they don't really have a email at Amazon, they'll usually just use their badge. So, we can use the the the chip inside the their badge to generate to sign something on the identity to gener uh to generate their anonymous identity to vote on something that they want to report inside Amazon. And further we can um like the landlord case we can use zko to generate a web proof about uh people transferring fund transferring rental payment to specific account to verify they are putting money or paying money to the same landlord. Um and yeah in general other use cases that we can just abstract this from the user that we can use any kind of public key public identity public string as the identity input into the group to generate the private identity. So after we collect that identity we'll let the user um registrate um into the system.

Um now we're only using um Merkel tree to check that the specific public key or the string identity and say inside the Merkel tree to verify um that this person belongs into this group. Um if you're in the ZK space you'll be familiar with this that it will be called semaphore. Um but I explain it about it why we are only going with the Merkel tree solution. So yeah so after uh the user register into the system if the user have a public key then they can use the public key as the identity identity generation otherwise we'll use something called vrf which is something um created by meta um what it does is that it can use a string or a any low entropy information put into the information uh put into the system and the system the VOPF will add randomness to that string to that input and generate a key pair for the user which then we can use to register into the system as the identity for the user privately. So that's a alternative and which make the system easier that people don't need to bring their own key into the system but that's something we can do and expand it into more uh use cases in web 3 and in ethereum.

So yeah that's basically what the registration part is doing. Then after uh we can prove that a c the user belongs to a certain group we then can pro can collect the vote collect the signal we call them attestation from the user in our T system that the user belong in the system and they want to vote privately on something either it is like voting on whether the user want to join a strike or they are providing a abuse information evidence on specific person inside the company. Um so now we just abstract it into a hash of private key and message that we allow user just to sign a arbitrary message to report on certain things. It can be vote, it can be evidence, it can be any information in general and that can be uh switch into a more advanced cryptography um primitive scope called plume um which is quite new. Uh but we then can skip the part of using private key and can use like more general information to sign something and after the vote has been submitted to TE we will then collect the information and then the TE now will receive the plain text of the vote itself so that uh it can sign in future.

So there's a certain trust assumption here um about the TE cuz it does collect information from user but um that's what we believe in TE right now. So we we let go of this assumption and uh keep the implement implementation this way. So the TE will collect the information from the user and once a certain threshold is meet that's for take example that if five employee report on a same boss about a workplace abuse related incident then the threshold can be set by anyone. So uh let's say five incident then once five people report on the same person the information itself will be aggregated into a anonymous array of information like um a abuse me at some time um during what night uh what happened like five different of message in a array will then be signed by TE and released onto the website or report to I don't know ministry of labor or to the HR department. Um it can be any solution but the point is TE will sign it and verify it's been collected from this system and the information will then be released.

So the reason that we took so many t step and of the system is that we want to create a layer of security because all technical solution has its um disadvantage and it have it might be break sometime so we want to add on different solution uh bit a bit to make it more secured in a whole system. So that's why we use TE as the first line of defense um to trust that the environment is safe and no one has the ability to touch it unless someone hold a gun and run into AWS um server and try to get the key out. Um and then we use the nonp proofs to prevent that once if the TE is really compromised. we can still have a certain degree of anonymous to prevent that people submit the proof will get picked out or will be identified and then um so every time the TE collect to the certain threshold and it released it we will delete all the information from the TE of the specific report and then signed it and released it to make sure that um once it's finished no data will stay inside our system. And then finally um the lesser assumption will be the per uh the people that register into the system either they provide their own public key or they use the VOP RF um as long as their public key and private key is not compromised then they will have the ability to recovery and stay anonymous inside the system.

So this is why we choose to go with this implementation have a layer of security because of scalable because TE we have been we have been debate about whether we want to use MPC although MPC is a mature technology but we feel like TE is simple um we can just abstract it as putting a server onto a trusted machine um so we don't have to take care of all the connection issue with the MP NPC while scaling and if a MPC server is offline how do we recover the data uh we want to skip that um discussion and just go with TE and for the key issuance we use VOP RF because it's easy to recover as long as this input is the same we can always recover the same key bear for the user and the downsides of PE are minimized because um the assumption will be people break into the AWS to hide eject the machine and we want to make it more um expandable so that user can bring in any ID from them with either the badge or the uh company email or um any general private public key and they can register into the system and we abstract the voting from not only abuse or vote for vote against something we abstract it into a arbitrary data field so so that people can report on anything decide on their use case and it'll be easy to customize with any kind of identity can register into the system and report and vote on opt. And now I'm going to talk a bit about the stuff we learned, the difficulties that we face that we hope you can avoid in the future. The first thing is on nor um we use nor inside the implement implementation this time we use primarily the zikk email north package and we're exploring the nor jwt for better UX. um difficulties that we face is that we want to use semaphore and zk rag x this time because um semaphor will be a easier solution to register into the group and to vote on something and the zkra will be easier to parse the information inside the email but they are both not supported in the current nor library right now so you'll either have to go with circum to work this So but but um from the ZK email team um these two library will be released in the next month or two. So it'll be pretty soon and we have a debate over ZK email and um ZK nor Jupt because um we believe that uh JWT will have better experience.

Um, for people that don't know JWT, JWT is when you use the sign in with Google solution. Every time you use that, it will generate a JWT for you. JSON, sorry, I forgot the full name, but it's JSON something token. Um, then that token will be used as the session verifier that you have successfully logged in through a certain email. So that would be better UX because now we use ZK email.

It's kind of compl complex because user will have to send a email to themselves and said that they want to join the anonymous coordination platform and we verify the email message and verify who sent the email to who and we verify that's from the same user. So it's kind of the the UX is not very good. So we want to sh uh change to nor JWT but nor JWT doesn't have any test in it. So it would be a debate into you want to have a more mature solution or you want to have something that have better UX. Um yeah so for the next step um this is what we have finished um what we have done right now.

We finished the system design. We finished the email identity verification circuit that allow people to verify their email and we finished the proof of voting. After they join the system, they join the Miracle tree, they can generate a vote on specific thing and then our server will aggregate information. And now we're in the part of implementing the server with the VOPRF key generation. And once we're finished that the next step will be moving this onto a TE machine and having client side proving to generate the email proof have a interface and allow user to um join the system and then switching to plume um so that people don't have to use the public private key pair to generate um to to join the system and then adding number of different solution to register into the system with the NFC card and ZKOS that we just mentioned.

Okay. Yeah. So that's what we have done through the last month at the privacy residency. Thank you guys for being here. [Applause] Any question?

You have one. more. What? What do you mean? What do you get more?

Oh, no. I'm I'm there's nobody else around you. Uh, is it easy to extend to like other messaging services and like why would I want to use this over something like signal or is just like the coordination effort of existing encrypted messages is not there? Uh yeah. So I think a alternative will be having a anonymous solution that where we verify the user identity um to see if the user come from at the same company and let them join the same group chat and talk about things that will be an alternative.

Um we have been discussing about that but that will require more complicated um reason because the current uh messaging or chatting app they don't verify user from a specific I don't know um company or from a specific team to verify their identity. They just let them join privately but we can't really know who are they. But in this system, we want to know that people come from the same team or at least know the people's identity to that to verify that they are in the group that can talk about specific things. Um like they came from the same company so they both know their boss so they get to talk about it. Um that's um what we want to do to verify the identity and so the current chatting solution don't have that um and the solution to allow people to um verify their identity and join a group chat talk about something will require something called FHE because once they joined um oh let's say if want we don't want to store anything then we'll use the FHE to trans um first to verify what they report that's say um a report on his boss b report on his boss and we want to use FHE to match the similarity between those message to verify that they are talking about the same thing um but FHE is pretty expensive so that's why it can't be done right now so the easiest solution will be verify identity and join a group chat and talk about it, but there's just simply no solution for that right now.

Would it be easier if you uh made an enterprise solution that the company could set up to make ZK proofs of the identity of the individual? Oh yeah. Um uh the the reason we started this is because there's a previous solution called Kalisto um which is created by Dean. Um what they do is that they allow um college student to report college or university campus sex abuse incident and they collect it together and match the information and pre uh generate key pair to people that report on the same thing and that them use that key pair to discuss. Hey, do you want to report this?

Do you want to bring this up? and then if they agree the information of their report will then be presented to the lawyer. So that's something they've been working on. the the the uh the pain point of that is that it's hard to convince university to use that because um either someone have to hold host this service host this machine um that will be I don't know a bit trouble um to find a group of people that know this know how to do this right with the good OBSAC and to do this um securely inside the university. I think that's the f the first issue and the second issue is that you still have to trust the university and the university will have to import the student list into the system so that they can verify who has the um permission to report um and they have to update that list I don't know um quite often if someone join or leave the university.

So I think that would be the two biggest um difficulties. One is uh trusting the university and second is the operation cost of running such system. So we we want to make it just easy to deploy either on TE to host it on a cloud service and using ZK prove so that it's permissionless. Everyone can just register with their college email company email. Yeah.

Thank you. Yeah. Okay. Thank you guys. Um, let's go to the happy hour.

[Music]