 So, I'm based in Singapore and I do R&D with the E&M Foundation on policy and geological applications. And today I'm just going to present something that I've been working on for the past two weeks in collaboration with the group of attendance team that's Patricia right there. Thank you so much, Patricia, for this really great talk. My pleasure, but it's not purpose to say it's me, we are like seven, so please raise your hand if you want to. Woo! Yeah, so today is all about how we use these proof of attendance tokens to enable anonymous voting using zero knowledge. And I am going to go into the demo, I'm going to go into the code, I'm going to explain how the system works and talk about how this relates to mixers and other applications of ZK technology on YouTube. So, let's just think about how to use it. So, let's say in the field there's always drama, there's always some control and the issue and there's always questions about whether we're going to include this E&M, there's half of whether we want to come to second on community consensus on some issue. And some people say, OK, we can try to use any election or voting to get some kind of like resolution. But that's fine and handy, but there are two problems there. You can vote as long as you have an address, which is not so good because you can create an address for free. And if you vote, you can find out other people's, or anybody can see who voted for one. And that's like a privacy. So, for this kind of use case, we solve for privacy using 7.4, which is a zero-knowledge signalling gadget, which I'll explain a bit later. And we solve identity by using the poll token because, for example, at DEF CON, at Apple events, at Hackathons, Patricia's team will hand out all these tokens and each person voting is one. You would make a poll token onto your address, and now you own that NFT, the ESE 7.21 token, which proves that you will end that event. And you could combine these tokens and say that I was at New York, I was at Singapore, and I was at DEF CON 5, something like that. So, we combine these two components to do a very simple voting act. And I want to explain how you can use zero-knowledge through this act to do voting. So, let's do a demo. Now, the activity is on the laptop, and you already have your NFT poll token. I would encourage you to go to one of those apps. It's on Mainnet. So, log in to your MetaMask wallet that owns the, on the address that owns that token, and you type in your poll token ID, which you can find on an EVE scan. So, for example, if I go to my MetaMask and go to EVE scan, I look at my ESE 7.21 tokens. You see that three days ago, I played my poll token. So, this is, my token ID is 4295, which is for DEF CON 5. I would type this token ID into this box, and I'm registered. So, that's just one transaction. It should cost less than five cents. And then, once you do that, you can go to vote. And you'll be able to see the list of questions that I could be able to see that with. And you can, and now you can, like, look at the answers. So, you can see, like, the proportion of people voting yes or no. And now I'm just going to do a quick demo of, like, adding a question and answering a question. Any suggestions for highly controversial topics that have nothing to do with personnel, no individuals, but, so no personal attacks, but any controversial issues that are going on right now. It could be fun. We could ask a question regarding holding the DEF CON 4 token also, and ask which DEF CON was better at that individual country. Should DEF CON 6 be held in Argentina? That's obviously yes. That's it, that's it. Should? Six. How do you start with the size? U, N, E, N, U, N, A, S. I don't know, I don't know. You have to know, like, the origin of the project. E, E, E. Yeah, N, A, S. O, S. Okay, so A, I, R. A, I, R. E, S. Okay. It's got to be 100 percent for sure. That's a... For sure. So what we're doing here is we've got registration papers on-chain, but for the sake of a demo, I'm doing a demo off-chain. However, just take note that everything I'm doing off-chain can also be done on-chain. So you'll need to pay the one transaction, which is 100 percent. Everything else can be done off-chain. So right now I'm just going to... Is the registration bit off-chain as well? The registration is on-chain. What would you do with off-chain as well? Like, prove in zero-knowledge that you have the probe token without ever posting anything on-chain? Not the way that the probe token is implemented at this point, because this is... Yes, you can send it off. So if you're registered, you'll have to say that this address was off-chain. What are we approving instead later on? Okay, sorry. Yeah, I'm sorry. Yeah. Yeah, but registration isn't here. It's the voting that's final analysis. So we're just going to sign the hash of the question. And it's going to be submitted to my off-chain database. And now I'm going to do the on-chain... I mean, I'm going to vote on the question, and this is where the magic happens. I'm going to prove that I am in the set of registered identities. And at the same time, I send a signal, which is the answer, yes, to the back end. The back end is going to verify that I am and that the proof is valid, but when they do that, they don't know which identity I am. Unless I'm the only one, then it's obvious. But if there were like 10 people registered and I make a proof, it only shows that I'm one of these 10 people. So this is like the ZK Snaps. And ZK Snaps, basically, I wait for you to verify computation without running the computation on itself. And so there's like two main steps. The first step is to generate proof. And this is something pretty cumbersome. It takes like half a minute to do. But the proof verification can be done in very, very short time. And it can also be done on-chain. For the sake of this demo, the back end is doing the verification on-chain in my server running somewhere. And you can generate proofs in a browser. And so what happens is that we generate proof in a browser, send it to API, send it to the back end, back end verifies a proof. Updates to database in the proof is valid. We also have a mechanism where you cannot pull twice. And this mimics the on-chain behavior of this non-contract that provides you from running twice. So this is going to take a half a minute. And I can jump into like the mechanisms at ZK Stacks. How ZK Stacks work, but... So I haven't got my... Let's say I have the set of the Perk token holders. And then I meet a new Perk token because I came late to DevCon. Does it have to update your registry or... You just have to register. So will it just... Will your circuits be able to just pull from the 7.21 contract? Or do you have to update your hash? The list of registered identities is whoever registered through this app. So you can claim your token and you can still have to register to use this app. All right, so the answer is yes. And I'll encourage anybody even when I talk to try this out. Unfortunately, it's not super mobile friendly, so I don't think that it will work on mobile. Yes. What's the URL? One of us.app. Any questions? Before I jump into this case. So when you vote, you won't actually make a transaction on chain directly but throw it on API so that your identity is not leaked. Okay, so in this case we send the vote through off-chain to the again. But the reason for that is because it's a demo to demonstrate how it works. In a better, in like a production application you would send the vote like through TOR or something to an API of a relay that would relay the proof to the contract and receive a reward from the transaction. That was something that I would cover a bit later. But in this case, we're sending through an API not because we're on piracy but because, first of all, it's a demo and second of all, even in production we will send a proof off-chain and then a relay will send a proof onto the chain onto the contract to register the vote. But if we make the transaction directly then people will be able to assume that we are required to vote. Right, so the only transaction that can be linked to your address is the registration transaction or the transaction that adds an impression to the vote system. But when we answer the question we generate a proof and send the proof to a third party relayer that does the transaction and pays a gas for you. And the relayer is rewarded by... So this is like on a tangent, right? I'm just going to, anyway in the on-chain version one idea that we had is to is that when you ask a question you will have to send some eaves along the question and the eaves will be stored in the contract and when you answer the question the contract pays back a small reward to the relayer that sends the transaction and that's how the relay is incentivized to relay the transaction in the first place. So that's how you get away with not paying gas for voting. Because the people who ask the question could subsidize the gas for the for the rest of the business. But for this demo it's entirely off-chain so I don't know as soon as there's no complexity on that. Okay, so now I just jump into the technical explanation of how this stuff works. So, right, so just to summarize what you saw was entirely off-chain registration but there's only one that goes on-chain. There's a backend server that checks whether the user has a vote token. It does the CKStuff proof verification off-chain and votes are stored in SQL database and there's also a they also check the hash of the the answer and the identity to prevent double signalling. So, I can explain what an excellent nullifier is there but this is what prevents the same user from signalling twice to a question or voting twice on a question and this mechanism that has an off-chain is what I'm doing to make what the contract would do on-chain. So on-chain, as I mentioned just now, there's really a reward mechanism and the smart contract verifies the CKStuff proof and only drop house a signal or a vote if the proof is there. So, what is going on here? So, we have two layers. The first layer is basically the voting layer. It's a smart contract that takes in the questions and answers and the registration but that's the interface on top of what we call semaphore and semaphore is like a base layer of CKStuff or zero-knowledge applications like this. So, semaphore is what we also use for mixer but semaphore is super-generalized. What it does basically is two things. First thing is that it allows you to register your identity. Second thing, it allows anybody in this pool of identities to signal an arbitrary string. By signal it means drop house any string to the Ethereum blockchain. But when it do that they have to prove that they are one of the registered identities that had registered themselves earlier. So, from an attacker's point of view all they know is that there's a list of registered identities and there's a list of signals but we don't know which signal is linked to which identity. So, in the same way an attacker knows it's a list of attendees who have registered onto this app they know there's a bunch of folks but they don't know which identity is linked to which code. Unless everybody votes yes to having that considered for the virus or unless there is like only one person voting then it's kind of obvious. So, this mechanism depends on whether to succeed depends on having a large enough group of registered identities who vote. Otherwise you can use heuristics to try out who voted for what. And 7-4 is basically to reiterate it's a base layer for these search applications. Other applications are like a mixer anonymous login even probably the state micropayments. So, there are a few ideas so this comes from Mary Pytan and Koby Gurkan from EF and they've been like, I think in other talks they've been talking about 7-4 and this is just one indication of this. Yeah. Okay, so, if I could go even deeper into the the 7-4 7-4 circuit are there any questions about this? So, if you want to use this scene to do a national election you first have to register everyone on the chain which would be kind of expensive. Oh, wow. I can't claim that this would be useful for a national election. Because the logistics way too hard. The security is the state way too high and if this gets hacked then the countries will actually get hacked. And it's not so fun. But what we are doing here is like an analysis to like for example, where Singapore ran from there's this like, so Singapore's independence was like 1965 and even then there were elections people were told that they were for secret and after today every year I mean every five years of the election the government says your vote is secret because they want to instill a certain amount of trust that their vote will not be tracked and it's like super to believe that because if they don't believe that they're not going to vote in the way that they want to out of fear out of some kind of sense of being watched. And I think if we don't have that in New Zealand then when we vote in the Dow we are not necessarily voting for the best interests of the Dow we might be voting for some kind of other kind of incentive which we don't really want to align incentives through fires. So this is just one option that might be able to help that but I don't really think it might work by election but in Singapore they burn the votes every time there's a connection they burn the votes a few months after the election so you don't know who will vote for you because they are telling a true plan. You vote here, Siebel. Yes. I'll tell you, instead of you managing the registry the user registers himself that can only be done with an identity token which is kind of cool. It would be interesting to let the users add other identities because if you like to increase your your set I might register three or four other token holders and then I register myself to expand the anonymity set. Right. Identity is a very tough question. So that's that to be done separate of the three to start performance. It was to solve for six people voting for Buenos Aires problems so I could have registered there's 6000 tokens so I could have registered my own token ID and then I would I mean we are assuming that each person only has one token unless you steal someone else's token nothing can do about that. I think he meant that the registry there are six in your controls there are six actors who can control them all. Yeah, yeah that's an assumption that we assume that there's no collision. Okay, so this is the last slide because I expect everything to diving into the ZK Starks might be a bit complex so I'm just going to do this very slowly and start by step. So in this audience how familiar are you with ZK Starks? Have you at least heard about it? Has anybody rolled a ZK Starks circuit? Okay, has anybody Alright, so let's just jump into the code, shall we? Yeah Who doesn't know how ZK Starks work? So who doesn't know the ABCs of ZK Starks? Should I go into the pipeline and talk about proving keys verification keys and things like that? Yeah, yeah Okay, I think I just stood by the other one. So just to recap ZK Starks are basically the ability to verify computation without ZK Starks are basically the ability to verify a computation in a short amount of time regardless of how large a computation is without revealing certain inputs to the computation. So for example, let's say you want to say that you have a function that I have some text and let's say this is a hash function right? So let's say that you have this hash function the hash of W is some gibberish So the first step you do is that you encode this function into a circuit and now we have a circuit and the first input is W and the second is H The code of F is encoded in a domain specific language that's used to program the circuit but there's an input W and an input H So we want to be able to prove that we know W We want to prove that we know that we know the pay tax of a hash without revealing what the pay tax is So this pay tax is a secret input and this is a public input So even though I say that this is a function and this is a circuit it's important to know that we don't think about circuits like black boxes we don't think about them as input and output We think in terms of whether this equality holds we want this basically encoding a bunch of asset statements and required statements inside a circuit so that this circuit or this proof would be valid if not only if all the constraints hold So it's not like a function in the traditional sense So we take a circuit and it's circuit C and what you do is something called a trusted setup So with a trusted setup you take in a circuit and then you run this process where you get you get two keys and you get some toxic waste So you run this process called a trusted setup you got a verification key, a proving key and it also produces some toxic waste which you must discard otherwise you can generate fake proofs and I can talk more about how to do this how to discard this in a way that's less non-trustworthy So when you want to generate a trusted setup proof, you need a proving key So with a proving key So if you generate proof you need a circuit you need a proving key and you need the witness The witness is a secret anchor Do we need a public anchor? Don't think it's alright When you generate proof do we need a public anchor? I don't think so We only verify it We only verify it Let's just go a bit What? Public inputs are inside the witness Public inputs are inside the witness Ah, thank you So it's so many details I just have to go up my memory So we generate a proof this way and when we want to verify the proof we use the public inputs H So if this is true it means that I know the witness I know the plain text of the hash H given the verification key and the proof If it's false then I don't know it So that's ZK Snacks 101 The the big problem with ZK Snacks is that you have this trusted setup where you need to generate the proofing key and verification key but you also need to discard the toxic waste and this is something that is really troublesome to do because the way that the best way to do this is through a multi-party competition where you have a bunch of people to do the trusted setup in step-by-step phases and you only need one person to be honest all these people who do this trusted setup it's called the powers of tower ceremony and for summer fall we are doing this thing called the pancher powers of tower where we are coordinating with more than 20 people so far to take part in the ceremony to generate to do the multi-party competition for our trusted setup so as long as only one of these people is honest the whole thing can be trusted this in two years ago when they are sampling powers of tower tree trusted setup this stuff is not new but can be a bit mind-bending so please be patient while you are trying to navigate all this complex stuff so we are going to take this and apply this to summer fall just now we mentioned how the circuit this is super simple circuit the function that hashes piece of text that returns a hash but summer fall is basically so the circuit checks whether the hash matches the the hash input the public input matches the hash of the witness or the secret but summer fall is doing something a bit more complex what we are doing is summer fall is proving three things the first thing is that we are proving that we have the valid mark of proof to the mercury stored in the smart contract given given the identity commitment that we want to prove knowledge of so what is an identity commitment so earlier when we registered our identity into the app we what we did was not just summer transaction but along the transaction that's the hash of an EDDSA public key and two random strings so this is all these identity commitments are stored in mercury as a lease on the mercury and the route of the mercury is stored in the contract is stored in the summer fall contract when we generate the mercury proof we download all the leaves we generate the mercury path and that's the mercury proof and when we and when we generate the proof one of the private inputs goes into a circuit and the circuit verifies the mercury proof and only if the mercury proof is valid along the two other conditions it will be a valid proof so there's a first thing we do to prove that the user is indeed but also there's a first condition that needs to hold for the circuit to be valid any questions so far yeah so if you don't know the answer that's fine you're wearing Z-con shirts so maybe someone else will know the answer in the crowd how in terms of complexity how much more complex is this than what Zcash does when they're signing transactions this is like way simpler than Zcash really? yeah Zcash is a super complex because this is just one note of a single denomination so what I mean is that each leaf only represents in this case it's just so I'm not so familiar with Zcash but this is way simpler let me just log in any other questions before I continue why don't you say a little bit about the size of the circuit and how that impacts what do we say the size as well as how reliable the answer is so before the Istanbul Hanfog if we use a circuit which supports a mercury of 20 levels so that's 2 to the power of 20 leaves that can be stored inside the contract which is basically 2 to the power of 20 registrations that takes like 30 seconds to generate a proof on the laptop and that takes like 800k gas to verify I think it takes 1 by 1 minute to deposit too but for this use case we lower the number of leaves so 2 to the power of 12 is like 4,096 and that's likely the attendance of that card what is the second part of the question about the size of the circuit is driving the power of the polynomial which you need for the field of the curve so if you're choosing if your power is not high enough then the verification is necessary even if it says true is actually false because this is only true up to an epsilon and the epsilon is a function of the power of the polynomial I think I should defer the question as someone who knows the math at lower level but that drives complication complexity to generate the witness I'm not super sure he catches like it starts at 2 billion I think that polynomials with power I would have to check with people who know the details so anyway so that was just the first part of the proof now we want to prove two other things the second thing we want to prove is that the signal was only broadcasted once which means that we want to prove that there will be no cover maybe we want to ensure that you cannot vote twice so there is something called a nullifier hash which is a hash of the identity nullifier which is one of the random value cells hashed along with the public key when you register into a smart contract you also want to hash it along with the external nullifier which is a hash of the question asked by the user and finally the path so the contract stores all the entire hash and the circuit also ensures that the hash is valid just like how you hash it in this center circuit and finally we also do EDDSA signature verification to ensure that the public key that was that the owner of the registrant has is valid and this is an EDDSA not an ECDSA public key so the reason for that is that EDDSA public keys are much more friendly for ZKSNAP and not so much for ECDSA keys which means that ZKSNAP applications on ETH have some challenges in terms of UI UX because these keys have to be stored somewhere other than the user's wallet such as in local storage but just yesterday there was a big announcement by Metamask where they have a plug-in system that lets you have something called add keys so there's something that we're going to explore and figure out if that's possible to use instead of storing the keys in local storage so just to recap this seven-force circuit proves three things that the user's identity is part of the set of registered identities that the signal was only broadcasted once and truly owns the key that was used to truly owns the key because they had to sign the message and the circuit revised the signature and also to recap the signal that we are broadcasting is a hatched answer we are broadcasting a signal to a question which is hatched to become a excellent nullifier the seven-force contract supports multiple excellent nullifiers and that's how we support multiple questions yeah so before we jump into more code can we any questions yeah tell you what I will jump into the maybe flow of how this whole thing works start to finish from the UI all the way to the signal circuit just look at the code so let's start from the front and look at what we do when we register because that was the first thing we did basically this is like a React web app when we register we generate an identity commitment and this function basically hashes together those three things right so we are using a keyless and hash to have the public key of the user and and two random values and something called live seven-force which is the npm library that extracts over a lot of the cryptographic operations to use seven-force so it sends it to the contract there's a transaction when it's done we just tell the user and then when you submit a question this is where it's okay that the user sign it using a personal sign function and we submit that to the backend database I think what's more interesting if I show you what happens if it's done on-chain if it's done on-chain registration is the same because we already do the on-chain for on-chain registration basically you insert you just pass along the identity commitment to the sample of our contract when you submit a question we are adding an external modifier to the seven-force contract and we also for this version of the of the voting app we require the user to send some ease along with the transaction and this is one case to be laid out later on so this we could be any amount but it should be enough to cover at least a few a few votes and then when you answer a question we hash the answer and we first of all check whether the question that is answer 2 exists and then we submit this to the seven-force contract that along the CK start proof whose parameters are the CK start the CK start and also these are the public inputs to the CK start which hash function do you use? hash function for answering a question yeah hang on we use Kijang but as long as it returns 32 bytes so now let's go one layer diva by the exception of the diva we are going to the seven-force contract so all this is open source by the way so if you have like some kind of application that wants to use ideal knowledge but you don't want to lay around with building a whole new circuit this might be what you need it also helps that we are also doing like a trusted setup add an audit for the seven-force code so when those are done you won't have to run your trusted setup audit for this component so in serve identity this is the function and seven-force that adds the identity to the on-train and broadcasting a signal is where we first we basically check whether the signal at the CK start proof is valid and then we just add it to the signal in the smart contract and this function to check whether the start proof is valid is here by proof is inside this smart contract code verify it or so this smart contract is auto-generated by a library called CIRCOM and CIRCOM is the JavaScript based library by IDENT3 that lets you write CK start circuits and when you write a circuit you can when you compile a circuit you can also auto-generate this solidity contract that allows you to verify proofs so now lets go one more layer deeper into the seven-force CK start circuit in this case we are looking at both circuits are made up components and this is the main component in this case the main component is seven-force this is where we define the signals so these are public inputs and these are private inputs so the private inputs include the identity the public key and the components that compose the identity component as well as the signature that was generated and the birth and path as for the public inputs those with this and the excellent amplifier so this is where it gets really detailed and there are a lot of projects using CIRCOM such as CKROAR that also do a lot of mercury verification I mean signature verification and mercury mercury proofs but just in a different way because they are using it for replication transactions so this so let's look at a simple example so let's say we want to verify that the identity commitment is valid we are going to check whether the hash of the three-point components, the public key identity track dot, identity amplifier matches the given identity commitment so circuits have inputs and outputs no circuits and inputs and as long as the inputs are valid then the circuits are valid so we have a component called a partisan component that does a partisan commitment which is like an hash function that's friendly for snacks and what we do is that we take the public key the bits of the public key we do pull them assign them into the citizen hash component and we do the same with the identity amplifier and write it in the track dot so the thing about this DSL is that you need to do a lot of bit-level operations which is super tedious and so credits all go to public government who wrote all this some of them are way further than mine and we do the same for other components that do other things with the CT stamp and at the end of the day if all these all these constraints check out then the whole circuit is valid and moving out the stack you'll see that this smart contract to verify the proof written truth will go up back to the semaphore contract that will pass this function will execute successfully and and that's how you do folding with a semaphore so I know I covered a lot of detail in this and there's so much more to go so I would encourage everybody to join the semaphore society telegram so there's a lot of the research and development into CT stamps is happening and this is also where the mixer was born the mixer that uses semaphore was born and we just yeah the internet is not working for me right now but I know on there so if you go to the Obinko GitHub you can see the link to the telegram group I encourage anybody to approach me if you have any questions about how to use semaphore and if you want to contribute and if you want to apply it for your applications I am writing something called live semaphore which is a mkm library that allows you to use it more easily and I'm going to write blog posts and documentation to help developers to integrate this better into their tabs yes it's pretty cool that you built this in 2 weeks and I just was curious what were some of the challenges you were trying to build something like this it's done in 2 weeks because I complicated my own code from the mixer yeah like if you go to the mixer this is like you go and test that you see that the UI I built is almost the same right yeah so this is like another application of semaphore which is the mixer I gave a talk about this 2 days ago you can basically when you deposit F into the mixer what you are doing is registering your identity and then you withdraw your second signal and because you cannot send the same signal twice you cannot expect link deposits to signals because you cannot link signals to identities you cannot link withdrawals from deposits and it's how the mixer works using semaphore as a base layer yeah so just to give a quick demonstration like just now it's going to download the leaves of the developer tree generate the worker proof submit the proof to a relayer to get some users to have and the user gets back so it's like the same design for the application so I guess my question is like were there any challenges right there's a ton of challenges because I guess I guess the first thing is just grabbing a header ground all the different types of firefighters and different types of cryptographic primitives that I use you can't even use like SHA-256 hash even though it's fast and traditional that's super slow it snacks and get into that understanding the fact that there are different hash functions that perform differently it's itself like one of the herders that people have to get through to understand this whole thing because within snacks the math is kind of different so that's one of the extractions that we want to help people not have to worry about when they use hip-center form initially the hip-center form I'm still working on documentation and guides but it's on MPM so all these functions should help developers to use this system I would have like 7 minutes to go maybe I'll take like 2 more questions and I will ask 4 questions if nobody's still interested have you thought about people like sell out down buying new boats wow the drew series running around telling everyone the boat for the Buddhist areas prove it so the ability to so maybe in your double spend example for micro mix it might be interesting to like you can only spend once but inverting it might be interesting to this very multiple times so right so not super sure but if you look at another application that's being built it's called this is like a separate project when you're also using a snag to prevent pollution in doubt behind this is that using a ck snag you can 1 plus 2 buy a boat because someone could boat again and make your boat like now it better but it's like I don't think it's doable with 7 or 5 any this is using a completely different circuit but it's using similar materials and similar concepts did you see Phil Diane's talk I got told to someone I think that's him his research is basically how can you prove and like float twice and stuff should look at that this is a very similar work and the collision stuff there's a bunch of people trying to do this also thank you for your thank you so much