# Semaphore V4

- Speakers: [Cedoor](https://streameth.org/speakers/cedoor)
- Channel: [Devcon 7 SEA](https://streameth.org/devcon_7_sea)
- Date: 2024-11-12
- Duration: 17:15
- Watch: https://streameth.org/watch/67330d403a168eb535f16a2c

## Description

Semaphore is a protocol enabling individuals to prove group membership and send messages (such as votes or endorsements) anonymously. The latest version enhances efficiency and simplifies the use of libraries and contracts. This presentation will cover the new features, project vision, and the importance and challanges of zero-knowledge technologies.

## About the speakers

### Cedoor

Software engineer. Enthusiastic about privacy and cryptography. I have been working on zero-knowledge technologies for 3 years, focusing mainly on developer experience.


## Transcript

Hello everyone, my name is Vivian Plasencia and I'm a software engineer in the privacy and scaling aspirations team at the Ethereum Foundation. And today I will be talking about privacy preserving groups. Privacy preserving groups are groups where the identity or the actions of the members is private. There are a lot of use cases for this type of groups and one of them is everything related to anonymous interactions like anonymous feedback, anonymous voting. There is also an interesting use case related to proof that you own a credential. So there are a lot of credentials that take time to prove and verify. So something that you can do is to ask people to verify the credential once and then add them to a group. And then they can just, every time they want to prove the credential, they just have to prove that they are a member of that group group and that's a cool use case of this type of groups because you can keep privacy. We cannot talk about groups without talking about anti-civil mechanisms so there are a lot of ways to use anti-civil mechanisms for your groups and an anti-civil mechanism is a method to prevent fake or duplicate identities in your group. And something interesting that you can do to have a stronger anti-civil mechanism is to combine many anti-civil mechanisms using logical operators so that you have a stronger anti-civil for your group. There are a lot of examples of anti-civil for your group. There are a lot of examples of anti-civil mechanisms so one of I will mention a few one of them can be like in bytecodes you can send people in bytecode and they can join a group and another can be like social media information like github followers or personal stars and also a number of commits on a specific repository, also Twitter followers or if you follow a specific user. Those can be anti-civil mechanisms from Web2. And there are also anti-civil mechanisms that we can get from blockchain information, like your account balance, the number of transactions. And the identity protocols are also a nice way to have anti-civil mechanisms for your groups. An example of this is AnonAtar and also OpenPassport. There are a lot of other protocols that are really cool anti-civil mechanisms, like Ethereum Addestation service, SKIMail, TLS Notary, and POP. So some projects can be useful for privacy preserving groups and also for anti-civil mechanisms. One of these is Semaphore. This is for groups, anonymous interaction, but it's really useful for if you are part of a group then you can be added to another group just if you are part of another different group. So also SUPAS which is a project that we are using here it has groups and also can be used as an anti-civil mechanism and Bandada which is an infrastructure to manage privacy preserving groups. And it also has a lot of credentials. And CKKit, which is a set of libraries and algorithms. So that also has groups and can be used for anti-civil, too. So the three main ideas from this presentation that I would like you to remember are privacy privacy groups can be used to verify credentials to have a better user experience in your applications. Also that you can combine different anti-civil mechanisms to have a stronger one. That's very important. Maybe it's not your case, case for your application, but it can be the case for some other applications. And some projects can also be used as an antecedent mechanism. They were not created for that, but they are really useful as an antecedent mechanism. So that's the third point. So thank you very much. And yeah, I will be around. Feel free to ask me any questions about these topics. Thank you. And yeah, I will be around. Feel free to ask me any questions about these topics. Thank you. Thank you, Vivian. We have some time for questions. Hi. Hi, Vivian. I've used Bandana before. I just find it difficult to understand. Like, this works with IDs, right? You get a group ID and user's IDs. So how do I use these group IDs, or what happens after I get one of these groups set up? Yes. Bandana is compatible with Semaphore, so you can use the Semaphore identity package to have the Semaphore identities, and you can add this commitment to a Bandada group, and then you can work with that group. And it's also, since it's compatible with Semaphore, you can do anonymous things with the members in your group any other questions it's over there I see some people wearing the mere cat hat unfortunately we're doing the rolling the ball of throwing. Yeah, please. So, quick question. So, are there any practical way to forcefully remove someone from a group? So, I understand that it's kind of easy to verify someone and try to add to a group, right? But, I mean, as the group have run, there might be a reason to remove someone forcefully. Are there any practical way to do that? Yeah, yeah. If you want to do it with code, there are functions for that. If you want to use it in case of application, for example, Bandana, you can do it directly in the dashboard. Yeah, there is an easy way if you are using code or not. Yeah. Can you explain the mechanic behind, like how can you maintain privacy of everyone and also can specifically remove someone? Yeah. In the group, you will have identity commitments, which is like a public key, like your account that is public and you have a private value. So the commitment can be public, and commitments are not attached to the identity of the real person. So you can, I mean, the person, it's a commitment. So people don't know, like, who is that commitment. Okay, thank you. Do we have other questions for Vivian? There's one question here. A lot of these privacy groups are opt-in privacy groups. Is there any opt-out privacy groups as well that you guys have looked into? You mean like if you want to be out of the group you can do it yeah like by default everybody yeah there is an admin and Okay. Thank you, Vivian. Thank you. Our next talk is also going to be about Semaphore v4. So let's welcome our next speaker, Sidur. He's going to show us some new features of Semaphore v4 and some of the importance of the ZK technology. Let's welcome him. Hi. So, hi, folks. I will start introducing myself, and then I'll present some news regarding Semaphore and our future plans. So, I'm Cedar. I work as a software engineer with the PSE team, and in the past years, I have mainly focused on improving the developer experience of some PSE projects. I'm talking about what Semaphore is. Semaphore v4, so some news. And then our roadmap. So, first of all, Semaphore, as far as I know, is one of the simplest client-side zero-log protocols. So the core circuits only contains 22 lines of code without documentation and, like, empty lines. Generating a proof only takes less than one second on browsers, and verifying a proof on-chain only consumes less than 300,000 units of gas, which means, like, around five cents on Arbitrum. But what is it? So Semaphore is a zero-knowledge protocol that allows users to prove their membership in a group and send messages such as votes or feedback without revealing their identity. In addition, it also provides an alifier mechanism to present users from reusing existing proofs. So Semaphore is basically a general-purpose protocol, so you can use it for any use case where you need a layer of privacy. We have been working on Semaphore for a few years now, and we have mainly focused on developer experience until v3 but with the latest version before we also focused on interoperability and efficiency and on-chain costs in particular we have made two important change we have a new identity schema which uses EDDSA keeper and we have optimized the data structure for groups. So let's go a little bit deeper. We replaced the old identity schema with an E-D-D-S-A keeper. E-D-D-S-A is one of the most efficient public key cryptography algorithms using zero-knowledge circuits, and it makes the new version of Sphemafor much more compatible with other existing protocols which use eDSA. In the old schema, the public commitment, which is like the public identifier of the Semaphore identity, was a Poseidon hash of a secret. In the new schema, the public commitment is the Poseidon hash of the eDSA public key. And in addition, it also allows users to sign messages and verify signatures inside and outside ZKey proofs or circuits, which has been and will be hopefully pretty useful for some applications like Zupass, which uses Semaphore v4. So then we optimized the old data structure, the incremental Merkle tree, and we created a new data structure, which is based on the old one,, the incremental Merkle tree. And we created a new data structure, which is based on the old one, the lean incremental Merkle tree. So just small improvements that made it much more efficient, especially when the tree doesn't have many leaves, so for small groups. The key improvements are two. Zero hashes are no longer required. And the tree grows dynamically now. So zero hashes. I just want to show the difference between these two trees. In the old implementation, if the parent node has one child, it will be calculated as the hash of that child node and the zero hash. In the new implementation on the right, the parent node can actually equal the child node itself, so no need to calculate any hash in those cases. The second important change is about the dynamic depth. In the old implementation the tree has a static depth. Each insertion needs to update a number of nodes which equals the static depth of the tree, and in the new implementation, the tree depth grows with the number of leaves, which means each insertion would only require updating a number of nodes proportional to the current number of leaves. So this is quite complex. So please, if you want to know more about this data structure, go to the paper we published a few months ago in the ZKeyKit repository below. Finally, what we would like to do in the next months, we would like to have a new Explorer, which people can use to see on-chain groups, and which admins can use to create and manage groups. We would like to work on a new version of RLN which is pretty similar to Semaphore. They share the same code but RLN works with an additional layer to prevent spam. We would like to add additional tutorials to the documentation and possibly have like specifications for Semaphore v4, something that people ask us a lot of times. We will also explore and consider improving systems, of course, and try to keep ourselves updated on the latest technologies to improve the key requirements of the protocol. So some links you can use to connect and ask us any questions. Yeah, thank you very much Thank You Sidor any questions oh there's one there do you want to give it a go it's on your side hello test thank you for your speech it was good I'm just curious to know more about Semaphore's business model. The tech sounds amazing, but I'm curious, is there a way to generate a profit from this? No. I mean, we are funded by the Thiem Foundation, and we are not thinking about any way to make profit. Okay, thank you. I think we're also not allowed to speak about profits, just from what I heard. Okay, thank you. Hi, I was wondering, to upgrade or migrate from previous version, does that mean like existing project need to generate new identities? 제작진이 새로운 정보를 생성해야 하는 거죠? 네, 새로운 정보를 생성해야 합니다. 그리고 새로운 정보를 생성하는 방법은 세마폴 B4의 정보를 생성하는 것입니다. 그래서, 이전의 정보를 생성하고, 전기 문제를 생성하는 것입니다. and then deriving the private key from the previous secret. I have a question for how the protocol works. Do all the nodes need to be online at the same time? Where are you, sorry. Hi. Sorry. Hi. Hi. Do all the nodes who want to take part in this protocol need to be online at the same time, or is it possible to establish the group without all the participants seeing the other participant at any point in time can you repeat your question sorry about it's about the liveness of the participants yeah so can we establish a semaphore based communication for example even if some of the nodes are only online for a certain short period of time or do they all have to be online at the same time to calculate these secrets yes they have to be online yes on chain at the same time okay thank you Thank you. Any other questions? We have one at the front row here. Hi. Hi, what are the advantages of using the lean IMT now data structure for like the aerodynamic depth of the tree? I think one advantage is that with the old static with the old incremental Merkel tree with static depth we had a range of three of supported three depths from 16 to 32. And even if the group is small, like with 10 members, you had to use a Merkle tree with a static depth which was like 16. So bigger... So it's a storage then? Yes, for storage. And the generation of the proof as well needs more time because the circuits have more constraints. Okay, I see. Thank you. Okay, we still have some time for questions if you have any.