 Okay, so last year around January, no around December the year before Yeah, around December last year. I started to work with snacks and snacks are applicable to two major things For privacy and for scalability. So today I'm going to talk about two applications to privacy and one application to scalability So the privacy projects are called Mixumis and Semaphore. So Mixumis is a is a is a generic Ether and ERC-20 token mixer where you can deposit one ether and later you can withdraw one ether and there's no way to connect the deposit to the withdrawal And Semaphore is very similar architecture and we use that to do To do general reputation mixing Yeah, so so you can you can become part of a group and you can signal things about your thoughts or beliefs or other things and No one can connect All people will know is that you're a member of that group and then we also have some rate limiting things there as well So that we can do like cooler public systems, and then we'll talk about snacks for scalability. It's okay. You can come in And we'll talk about we'll talk about snacks for scalability So so basically we'll we'll build an elliptic curve inside the snark And we'll use that to make signatures and we'll use that also to do peters and commitments And then we then we sort of join that all together to make something called roll-up where what and how what roll-up is is roll-up aggregates transactions together in order to It aggregates transaction validation So instead of having to verify ten thousand signatures inside the EVM you have to verify a single snark proof You can come in it's okay. Oh, yeah Yeah Who said that? Okay, so Yeah, so so then so that's that's what we use we use that's what roll-up is. Yeah, it's just a it's a scalability solution okay So first what is a snark? Okay, so snark is a snark is a way of proving that you did a computation without To the proving or proving that you did a computation correctly. Yeah, so the verification of a snark is succinct oh Wait, I'll say that later. So Given given some Impots and some code that we predefined before we'll get some outputs. Yeah, that's what that's what a snark proves. Yeah Proves I run the code with the inputs and got the outputs. Yeah But then we can do cool things right we can sort of hide some of the inputs and some of the outputs Yeah, and that's this is where we get our privacy Properties right because we can start to hide things So or we can hide everything but that doesn't really make much that that kind of makes sense But not in not in a lot of applications Okay, so so for the rest of the talk we'll just talk about this code Yeah, so in the center box inside the snark we have this code that defines what we're verifying So we'd use that to verify that yeah, so so that's the central problem that we're trying to solve Yeah, that it's difficult to make this code that that verifies That yeah, so it's difficult to define the computation that you're verifying you did correctly So so that's what we're gonna talk about later or that's like that's like the main theme of this talk Yeah, that we'll go through that and we'll see how it applies to three different solutions. Okay Yeah, okay, so how does this relate to a theorem so so we can validate snacks inside the EVM Although it's a little bit expensive it costs about 500,000 gas at optimal to do that right now But there's the there is scope to reduce those costs So And this means we can have privacy and scalability Yeah, we can have privacy by just hiding the inputs that we have and we can add scalability because the the valid The verification of a proof is succinct It takes the same amount of time no matter how complicated the the the code that you are verifying is Yeah, so for the rest of the talk We're gonna define the code that we saw in the previous figure here. Yeah, we're just going to define the code that defines the snack Okay, so a lot of the time in blockchain we talk about a Lot of the time in blockchain we talk about Merkel trees right because the Merkel trees are a good aggregator of information. So this is how a Merkel tree works So basically you have a b c and d and those are the members of our group and we want to aggregate those together to a single Root yeah, so what we do is we hash a and b together. We hash c and d together And then we hash a and b c and d together and that gives us the root Yeah, so so sorry, so we hash the hash of a and b and the hash of c and d together and we get the root So and then we can make something called a Merkel proof and prove that we're a member of and we can prove that We're a member of that set Okay, but so let's go forward. Okay, so let's let's think about this now. So so we can move We can move the the that a Merkel proof inside the snack Yeah, and this let's us do some really cool things Okay Just that's a smooth. Yeah Okay, so but but in order in order to so so we can do cool things here But but it's there's nobody has any permissions here, right? Because a b c and d are all public and that means anyone can prove that a b and c and d a b c or d are a member of our group But that doesn't really that doesn't really help us We want to we want to have a way that that people have some private information and they can use that private information to signal about To we want to we want to limit what people are able to do inside our system So the way that we do that is this that we come up with this really kind of naive We come up with this really naive kind of public key private key scheme Yeah, and the public key is defined as the hash of of Two inputs one called this notifier one called a secret and another fire in the secret I just random numbers. We just regenerate these random numbers and and We hash them together to create our public key and we and we give our public and then we do something else with the public key So anyone who knows the private key of the public key is able to make a signature But this is a little bit naive because if if people are able to make the signatures then they can always then As soon as you make a signature someone else can copy your signature because when you make the signature you reveal your private key So it doesn't really work But what we can do is we can put this inside the snack Yes, and if we put it inside the snack we can hide the notifier in the secret and that means that our signature scheme becomes kind of Yeah, that our signature scheme now makes sense Okay, people can make signatures and it doesn't reveal what their private key so we can do this repeatedly. Yeah Okay, so but but now this doesn't really make sense as I said before right because we have we just people can prove that They're a member of this group that Merkel that's defined by the route People can keep people can prove that they're a member But that doesn't really make sense because we don't reveal anything and if you give that proof to somebody else They don't even know what you're what it what it's talking about I mean, they just know that they just know that you're a member of song Merkel route and that doesn't that doesn't really make sense. So what so what we need to do is reveal the Merkel route. Yeah, and now it starts to make sense Yeah, that now the the Merkel route is public to the verifier and when they verify it They can see that oh this person must know the private key of a member of this of this group. Okay, oh Wait Where does it say the time? Is there some way for me to know the time? Okay, I can I can see okay, cool Okay, so so now we can use it. Okay, so this is already enough to do some cool things Okay, this is already enough to do To make a mixer. Okay, so that this is what the mix miss mark contract does first of all I use a deposit and either into the contract and And then the contract will allow them to add a leaf to to to to our group. Yeah Then a user can use a snark to prove that they know the secret information of a leaf in our in our group and users who prove this can withdraw a coin and This this word and because the only thing that we reveal in the previous Because the only thing we reveal is the Merkel route There's no way for anyone to know which leaf led to which withdrawal, but there's a problem with this So what does anybody know what the problem is? Yes? Sorry Okay, that yeah, that's also a problem, but that's not the one That's not the one that I contrived to talk about next So so yeah, that's definitely a problem But the way that we saw that is that we limited to to one ether per deposit and one ether per withdrawal And yeah, so it is a problem and there's ways to think but fix that and we can talk about those in a while But it has anyone another a problem. Yes Yes, exactly you can do a double spend right because nobody because you just prove you're part of the Merkel route Yeah, and people can people just take out coins again and again as long as you're a single member You can repeatedly take money out because there's no there's no sort of there's nothing to prevent You from from double spending yeah, it's a double-spend problem because you just don't have information about about who was withdrawn previously so Okay, how do we fix this problem? Does anyone have any ideas? I'll put balance Yes, probably no fire. Sorry. I didn't hear what you said. I said to add balance to the output Yeah, that would kind of work But if people because everyone uses the same balance it doesn't really it doesn't I could just deposit the same balance as somebody else And just take I could take all let's say one either is a popular amount I could just take one either is out a bunch of times, but yeah publish the nullifier exactly So so we kind of contrived to have this nullifier here previously as part of the public key And that's why I didn't just call it private key So so what we do is we we publish the nullifier. Yeah, we make that public and then in our smart contract We we remember that whenever someone uses a certain nullifier We remember it and then we prevent people from withdrawing with the same nullifier twice So this actually introduces another problem that we need to think about but it's kind of outside the scope of the talk But but the problem is that that there's like a griefing attack here That someone could someone could see that I'm trying to withdraw a nullifier X and quickly deposit deposit nullifier X again And then we draw that and then my withdrawal would fail But this is a griefing attack and it's like $1 for $1. I mean, it's very expensive to hurt people with it But yeah, it's definitely a problem But but yeah, there's ways to fix it, but it's kind of outside the scope of what we want to talk about Okay, so now we can check Yeah, so now every time we withdraw we make sure that that coin hasn't been withdrawn already Okay, so that's how makes most works. I mean, that's that's that's that's exactly what we have currently in the github Okay, so we have some problems with that And I'm one of the major problems is is who who pays for the gas, right? So the thinking is that if I deposit one either and then later I deposit another either I need to have gas in that account in order to pay for the transaction fee of the withdrawal and Because I can't do that. Yeah, because now you have a chicken and the egg situation It's like I have this anonymous money, but I need non anonymous money to take it out. So that becomes a problem So so there's a way to solve that I don't know if I talk about that in the next slide or not No So the way that we saw that is we do like layer two transaction obstruction, which is oh, it's actually called meta transactions That's the new name for it So what we do is a meta transaction where where people will get a fee for for broadcasting these proofs And the fee is like a portion of the amount of money that you deposited Okay, so then problem number two is that people can analyze the inputs and the outputs to track the users Yeah, and so this is more like a temporal attack and you can use these heuristics to let's say that let's say that I deposit one either into the smart contract and then I withdraw that one either in the next block I mean, it's very obvious that It's kind of obvious who who deposited yeah I mean you can't connect them cryptographically, but you can come up with these sort of clever heuristics about about how much you can How much you can take in and take out and and that's part of the reason why I prevented the having multiple amounts because Because if you have multiple amounts the amount that you withdraw is also an indicator of who deposited Yeah, let's say that I would deposit at one point one five six seven either and then someone later withdrew one point five six seven either It's a good bet that it was me who it was my withdrawal. I mean what we want to do is maximize our privacy set. So Yeah, so that's that's those are some thoughts on that So we have a proposal for the layer to transaction abstraction and hopefully we'll be able to sort of merge it with with someone else's But anyway, that's kind of kind of future work that needs to be known Okay So can we allow multiple deposit sizes and that's kind of that's kind of what I already addressed Yeah, it's also trivial to to to allow your C20 token deposits and withdrawals But we need to be careful about the privacy set again If these tokens have sort of low volume, then it's unlikely that people will be able to If these if these if these transactions have low volume and they'll be unlikely that people Yeah, I mean people might think that this is really super private and I might not be I mean it's just something to be aware of when when when we're thinking about these things because yeah, okay And then there's like other kind of further research questions about how can we can we Increase the size of our privacy set by being able to trade from one currency to another Privately and that would that would be kind of cool. I mean that would that would sort of merge our separated You see 20 tokens into a way that that we could into something that makes a little bit that has stronger anonymity properties But that that seems that seems to be a difficult a difficult thing to do But we can see that that's sort of future future work Okay, so so basically So that's the end of Miximus. Okay, so so that's that's that's all I really have to say about Miximus for now So it's a general token mixer that you can use to Mix your ether or your tokens. So this is this is this is like cool. It's nice work, but it's a little bit It's not really very It's it's very similar to Zcash's work and I mean it's similar to things that already exist I mean, they don't exist in the Ethereum, but it's like work that's been done before and it's cool But I would sort of search for other ways to use snacks to do other things So the thing that I'm actually more interested in is something called semaphore, which is which is very very similar to To Miximus so so instead of Instead of depositing one ether and being allowed to join the tree We come up with some other rule that lets people join the tree. Yeah, we could have like a Sign-in with github button and people who sign in with github are able to are able to join this Merkle tree and And then they can make proofs about things Yeah, and if they don't sign in with and we sort of limit the amount of members in the group So this this tree becomes like a proof of github. Yeah, and anyone with github is able to is able to make signals about things So how do we do this? How do we make like a generic signaling application? And the way that we do it is so so basically we have a lot of what we need already Yeah, it's very similar to Miximus. We have the same public key the same private key I should do the air quotes when I say public key private key We have the same setup and then we have a Merkle tree where we aggregate all of these together and then we put that inside a snark and We add you see here you see here in the inputs We've added the the idea of a signal so the signal is just like 32 bytes And it says it's the hash of something that you want to say I mean it could be the hash of a tweet or it could be the hash of Of a vote or it could be a hash of something else Yeah, so we include that Yeah, so yeah, so we include the signal, but we still have another problem and what is the problem does anybody know? Anybody know? So think think about the difference between what we do with makes Miximus. Miximus is we only want to use Miximus one time But this we want to use multiple times Does anyone have any ideas? So the problem is oh, yeah, sorry exactly. Yeah, so the answer is that you you you You if you reuse you we force you to reuse the same nullifier here And when we force you to do that you can link different signals together Yeah So if I say if I do one tweet and one vote the nullifier will be the same And I will I will be able to link those two things together And it still has like it's still anonymous ish, but because you can connect them together It's it's not really great because I mean because we don't really want to do that. I mean we want to be able to Tweet and vote and do a bunch of other things and have them disconnected from each other Yeah, so the nullifier last yeah links of signals. So how can we fix this does anyone have any ideas? Sorry How should we'd a counter? Yeah, that's right. Yeah, so we are so we add this idea of an external nullifier Yeah, so we hash the nullifier with the external nullifier inside the snark And I mean this gets a little bit a little bit messy, but but yeah, that works So we have this external nullifier and then we hash the two together. So now are our external our Our new nullifier Will be unique because as long as the external nullifier is different Then each signal is unique and we can limit people from making multiple signals about the same thing But we can't connect the same two different signals about two different topics together Okay Okay, so now I have two examples. Let me see what time it is. Okay, so this is this is looking good So we can we can talk about the at least this example. It may be another so so like this is this is this starts to get a Little bit complicated. So let's do an example to make it to make it a little bit clearer So so let's do first pass the post voting. Yeah, and let's just think about that So first pass the post voting is just where everybody votes and then you count the votes and whoever has the most votes at the end Of the count wins. Maybe that's not exactly what yeah, that's that's what that's what I'm talking about anyway I'm not sure if that's the technical definition of first pass the post voting, but yeah, okay So so let's say that everyone in this room comes up and we vote for Some decision. Yeah, whether whether zero or one whether Whether people thought DevCon was good or people thought DevCon was bad. Good. Okay So we have this binary decision and we and we come up with some framework. So we say that okay We all agree on on the same signal. Yeah, and the signal is Yeah, so we all we all agree on the same signal and the signal is that DevCon is bad And we have another signal and that signal is DevCon is good Yeah, and people can vote and we'll count up all of them together and at the end we'll We'll we'll we'll see who thought how many people thought DevCon was good and how many people thought DevCon was bad And then finally we need to think about our external nullifier So who thinks that we should use the same external nullifier for for both signals Okay, and who thinks we shouldn't use the same external nullifier for both signals Okay, okay, so if we don't use the same external nullifier for both signals then Then people would be able to vote. I think DevCon was good and I think DevCon was bad and we'll have no way to detect them So we need to vote. We need to have the same nullifier external nullifier for both Okay, and this way you can't you can link the votes together which kind of sucks But you also limit people from voting twice, which is definitely a good idea Okay, so now we can let's talk about something a little bit more complicated So we can also do like proportional representation And proportional representation is another form of voting where we're instead of voting like having a binary choice You can you can choose among multiple Multiple different choices. So the idea so let's let's expand our previous example where we had oh, I think that was good I think that wasn't bad and now we cannot a third one. I and say that I think Devon was okay But I think I think we can do better next year So that people can people can choose. Oh, actually, that doesn't really make sense I think I think I think it makes more sense for like leadership elections. So let's say that we vote between an elephant a giraffe and a kangaroo to be our to be our leaders, okay, and we want so Okay, so different people like different animals more. Yeah. Oh, let's change one of them to a lion So an elephant a kangaroo and a lion Yeah, because this this makes more sense. Okay Okay, so Okay, so we're voting between an elephant kangaroo and a lion right and we want to pick Yeah, so some people really some people really don't want to vote for the lion So, oh wait, I'm explaining the benefits of proportional representation and I shouldn't do that because I don't really it's not really on topic. Okay Okay, so Okay, so yeah, so so basically we can do the same thing But for the elephant the lion and the kangaroo they each have a different signal, but the external nullifier always stays the same Okay. Yeah, so that that that really makes sense and it's very similar to the previous example Okay, so let's just keep going. I mean, here's the current problems with with with with seven four So can we so can we build a proportional representation where you can't link the votes together because I mean in the previous example It's clear that we have to use the same external nullifier I have for each signal and that kind of lets us let's us link that Oh, I voted first for the kangaroo and then for the giraffe and then for the lion And that's that and that will reveal information about the electorate in general and maybe we want to stop doing Maybe we want we don't want to do that Yeah, so so that's one thing, but that's really complicated And can we do quadratic voting like this? That's another interesting question. There's like a bunch of applications for some before that that haven't really been explored Again, how do we pay the gas that is if you do this if you do this on chain But I don't we I haven't I've done a little bit of on chain stuff with this But in general it makes more sense to have it as an off chain off chain scalability solution Oh, no off-chain signaling solution. I mean it just works a lot better because you have to pay 500,000 gas for every vote Which is which doesn't really work very well Okay, and then can we make deniable signatures? So this is this is more to do with like anti-coercion voting Oh, no, bribery resistant voting or coercion resistant voting where where someone can force someone to Either through physical force or through money to or they can pay them to vote a certain way And this is about thing and we all agree it's about thing and we should think about how to solve it And there's and there's some ways that we can do it But they're kind of outside the scope of what we're talking about here But if anyone's interested to talk about that we can talk about it later Okay, so now now some more limitations of the snark work that we've done so far. So the proving time is Is quite long for for Miximus and seven four It takes about I have some numbers here. Oh Wait, no, I'll talk about that in a minute. Okay, so then there's okay So this is so so now we've talked about Miximus and we've talked about seven four and we see that It's we see that in that we have some cool some cool things that we can do with these So there's a bunch and there's a bunch of like open opportunities to continue this work and to do other cool stuff with it for example, we could have a Yeah, so example we could have we could we could build this kind of group I mean, we don't really have any groups in seven four yet And it would be nice to have a group of people who could signal about something together And then we can expand this so so one way to do that is to have a like it We have to have a way to limit the amount of people who couldn't join a group Otherwise you can just join the group and and signal about whatever you want Yeah, or do sock puppet attacks and things like that which we know a sock But it's a puppet attack is where it's where like you see this really interesting discourse on some social media platform But it turns out it's just one person with many accounts talking to themselves and it's a way to sort of propagate your ideas and and force the discourse on the topic in a certain direction and In general, I think this is bad and oh, no, I think this is bad and we should we should find a way to stop it So one way to so the way to stop it is to limit the amount of people who can join the conversation But we also want everyone to be able to join the conversation We just don't we just want everyone to be able to join once So there's a bunch of ways to think about how we limit people from joining them and one of the and one of the Ways is although it's really it's really it's not very strong. It's very weak is to have like a github based Merkel tree joining and we have some other and then there's some other ways to do it and I can talk about those later Okay, so then the next the next idea is to is to build on top of some sort of membership Requirements to build on top of that and to make some sort of social media platform So this this would be a little bit different than the the ones that we're used to that instead of having like a person Who tweets about something we could have a it's not a person who tweets about something we could have a group Yeah, you would join a group and your group would engage in discourse internally and externally So you could see a group of people discussing something and some of the people believe something and other people believe something else And I think that if we remove like the idea of the self from this I think we remove the idea of the self from this then we can I Think it will lead to like more open discourse So so this is like a sort of a philosophical tangent that I'm gonna go on But this is this is what I this is this is my sort of reasoning for this It's not like in general in life. It's normally it's easy for people to coordinate inside a group It's easy for people to say oh listen I think this and I think this and people have this sort of healthy discourse and then they agree or disagree and this is This is very good for everybody, but other but sometimes this is not possible sometimes like for example Sometimes a minority inside a group can be oppressed by the majority and the majority can impose some sort of costs on The minority when they try to coordinate and it comes and this will lead to a point where where the minority are unable to sort of Even admit that they're part of the minority Because they're afraid of oppression or something like that or they're afraid of some sort of consequence for this for this admission And there's been a bunch of rights movements that have been around that have centered around people saying that I'm part of this group and Revealing that and paying this kind of high social cost, but that's like not very good for everybody I mean there should be a way for people to coordinate without having to pay this high cost And one of the ways for people to coordinate and not pay this high cost is to make these like anonymous signaling groups Yeah, and people can say it can kind of anonymously say oh, I'm part of this group without revealing which part of which member of the group They are so they they they they can't be they can't be the victim of some kind of oppression because they they Or it's more difficult for them to be a victim of some kind of oppression and they're also free to sort of express disbelief and This I think is a healthy thing for society in general because people should be free to sort of coordinate with each other and express their beliefs and I Think that when yeah, yeah Okay, so that's that's like the end of the philosophical tangent But that's that's that's that's why we need to have these sort of anonymity system or Systems with strong anonymity properties So I'm very interested in people are in people who are interested in working on this in building things with them before and please Talk to me afterwards if you are there's a bunch of But there's a few people working on this and we're happy for other people to join and there's a lot of open opportunities So So then So then we can have anonymous credential systems And this is where you can just sign into something without revealing who you are and we can and that's a whole other use case that we can have Then we can have reputation systems And it's in fact we I found a way to build a reputation system where where you can kind of exclude someone from the group if they if they If they if they break some rules, so let's say that I have like a VPN server And I'm like I let everybody use my VPN server who's in this who's in this room I at the end of the thing I just go around and I collect everyone's private key And I say okay everyone's left to join but then Some someone starts to use this VPN all the time and they use too much of the bandwidth And I have to remove them from the system So this this kind of talks that this post here talks about how we can do that and what we can do Yeah, so this this post there's easy research post talks about how we can do that and and other things about that and Yeah, so it's sort of the limits and trade-offs and whether this is useful or not No, this is definitely useful So this is this is another kind of direction that we can go in with seven seven four Okay, so there's a bunch more stuff we can build some for and I kind of think that like Not enough people are working on this So I'm happy to sort of talk with people afterwards or during the question-answer session about this Yeah, hopefully we can sort of do some work together Okay Okay, so then also I want to promote this at snacks. So it's nice of Snacks is this Ethereum snag project that's funded by the Ethereum Foundation that are moving forward with some of the the lower level Cryptographic primitives that we need and they're doing a bunch of good stuff And if anyone has some C++ experience or wants to learn a little bit about snacks that this will be a good place to sort of Contribute there's also Zocker tease and circum. I think I have circum later But I'm sorry Zocker tease It's also a cool project. I maybe have them later so So we also use your C20 tokens. Oh, yeah, so this is other things we can fix with Mixmas, so we could Make a pull request to include your C20 tokens at snacks have Have Reimplemented it in a much more efficient way and it'd be nice to sort of port their work to the original repository Yeah, and then it would be good to merge Mixmas and 7.4 together because they're so similar It would just be good to have a single a single repository Okay, and then then there's other work to do we can replace the hash function in which I'll talk about in a while And then there's also a bunch more seven for use cases that that would be nice to explore and talk about Okay, so let's talk about some of some of the figures of what we have so so Okay, so So the hash function so we need in order to make a merkle tree in order to make a merkle tree We need to have a hash function and the hash function that we use right now is chat 256 and chat 256 It's very expensive to do inside a inside a snark because it's based upon binary operations and I'm gonna talk about that in a minute So proving time in seven four is about seven minutes and the the merkle tree the depth of the merkle tree is 29 Which means there's like 29 hashes So that's yeah, so it's quite expensive, but that it the tree is very big. It's enough for like 500 million people to join So on my laptop it takes out seven minutes and it needs a lot of RAM It's impossible to run it on a smartphone and this is a problem So it's about 50 K constraints per hash Which is which is which it leads to 1.5 million constraints all together And this makes the proof. This is the reason why the proving time is so slow So we want to minimize the we want to minimize the proving time So we want to meet over so we want to reduce the number of constraints So let's talk about how we can do this. Okay, so inside a snark We can do a time we can we can do this we can sort of check these assertions Yeah, we can check two side Chinese sign kinds of assertions We can say that a multiply by b equals c and we can say check that we can check multiplications and additions So we can also replace a and b with a bunch of additions of something else. Yeah, where it can be the sums sums of things Yeah, so then we can already do cool things with this I mean we can already implement every company any computation with this right because we and the way that we the way that we End up doing it is okay. For example, can can can anyone think about how to how to design an x or gate with this? I mean, maybe this is probably not a good interactive question But this is a good sort of learning experience to make an x or gate at the start and and just see how you can make these constraints Also, I have a list of these problems that that that are kind of interesting to approach at the start So if anyone's interested in that, please let me know Yeah, so shot 256 is binary opera has a bunch of binary operations one of them is an xor and then there's like Sigma shifting self and a whole other bunch of stuff So what we do is or what other people have done what the lip snack people have done if they've implemented chat 256 They've implemented it in in lip snack and and they've just built all the basic gadgets and plug them all together So we can we can we can already do this, but it turns out it's really expensive Because we just turn everything in the binary and inside the binary we use We can just do zero and one where we have we can actually do a lot more expressive things inside the snark So how can we can how can we improve this? So let's talk about what we can do inside a snark So we can do this a times a times b equal c where a and b and c are all these are sums And we can also but we have to be careful because we have to we have an overflow So snark's work over this prime field and if we get to this number Which is about 253 bits, which is 253 bits We will overflow and we if we add one more will overflow So we wrap around of this other number down here, which is about two to two fifty three bits So it turns so that means that we do all our arithmetic module P. Yeah, where P is where P is a prime number So does anyone know how this can be how we can use this? Anyone have any ideas how we can use this to build like an interesting interesting things This is a difficult question Yeah Yeah, okay, so it turns it turns out and we can use this to build elliptic curves Yeah, because okay, so if we take a look if we take an example of sec It's like P 256 here one, which is about where P is two to the two fifty six bits All operations occur module of P So it turns out that we could we could build a comparative elliptic curve inside the snark and do and have all our arithmetic module P done for free So so we just do regular multiplications and additions inside the snark and it would turn out that that would be that those those operations We're doing module of P so So why don't we do this with sec P? 256k one the reason that we don't do it with with this curve is Because they have edge cases at the when you when you try in double points, okay So if people are like strolling to follow that's okay I mean this is this is this is kind of a little bit difficult stuff and it's gonna get easier in a little bit It's just I'm just talking about how to build these crypto cryptographic primitives for like two more minutes And then we're gonna get back to the regular kind of okay now. We put this here and now we put this here And how do we build things with this? Okay, okay, so so the reason why we don't use the reason why we pay so we use a twisted upwards curve Yeah, we use a twisted upwards curve And these are the formulas and these are point additions We did twisted upwards curve because it doesn't have edge cases when you when you double the identity or you yeah When you double the identity or you are the identity to something else So in general in snacks, we don't want to have edge if we had an edge case We'd have to have if we had an edge case we'd have to have an if loop and if we have an if loop That's that's not very good inside a snack It's just really expensive to do an if loop because we have to do everything a times b equals c which which is really Okay, there's another example. How do you make an if loop with a times b equal c? It's totally possible, but it's it turns out that it's it's prohibitively expensive when you do it a bunch of times Okay, so this is the curve to do These are the point multiple. Yeah, so then so then okay So inside the curve we need to so we need to be able to do two things to do elliptic curve cryptography cryptography The first thing is to do point additions, which is easy. We can use these formulas here And we can implement those inside the snark easily and the second is to do Point addition point multiple scalar multiplication and we can do that too. It's just a little bit more complicated We just do a bunch of double ads actually scalar multiplication just degrades to just additions Well, yeah, we can figure that out, too And you yeah, we can figure that out, too and we can use windowed exponentiation we could switch to windowed exponentiation which will save us a lot of constraints and Ed snacks have done that already they're there now becoming the canonical implementation although circum have a competing one-ends Awkwardies are gonna make their own implementation soon. So we're gonna have a bunch of these implementations that people can use to Do elliptic curve stuff. I hope it's okay that I said that Okay, it's good, okay Okay, so then these are some links that will teach you about elliptic curve operations and how to do that And just a general background. Yeah, because this is this is I mean the last couple of slides were generally difficult stuff And it's okay that if you didn't understand them. I'm and now we're gonna get back to that Ah, oh, yeah, so I just have some future work about this. So and then we're gonna get back to the regular stuff. So Oh, I'm not sure that link is right, but you guys you folks can find it Okay, so so future work. So the first thing is that this this this work should be treated Yeah, this work hasn't been reviewed and I don't think that anybody should use this in production until it's being reviewed a lot This is like the rule in crypto is don't or the rule in cryptocurrencies is don't roll your own crypto And I did and this is Okay, so so please be very careful about this also if you have crypto Cryptography expertise, it would be I'd be very interested to talk to you about sort of real reviewing some of this work and So what more people can use it, but at least we should say that it's possible to do this kind of cryptographic stuff inside a snark This is yeah, this is at least an example of how that's possible So it's for pitiful hatches and signature scheme, which I'll talk about in a second Yeah, so okay, so we've got to get some review and here's where you can review it And then there's possibility that we could build bulletproofs in the same way and embed them inside the snack And that's a nice interesting. That's an interesting like a research problem And then there is also it would be cool if we could do like recursive snacks or at least recurs one layer And then we can do something like the SSC Paper there was this paper recently about using recursive snacks to do like private smart contracts So that that's an also an interesting Sort of future future direction Okay Okay, and also I want to say thanks to Daria Hopwood and For for for help and advice about this as well as the Zcash team who have done who I Who have done very similar work before me and really lit the way for me when I was doing this It's specifically this issue. You can see it's so cool They just describe everything or every single step of their decision-making and then there's they also have a blog post about about how about how to do it so very thankful to them and Actually, they're using it now in the wild so they just had a hard fork a couple of days ago another They're using Peterson commitments. Oh, yeah, so great. I should have talked about that. Oh, sorry I'm okay. So so what can we actually use this to do like what is the what is elliptic curve inside? It's not useful for and the answer is as you said Pedestal or is you asked Pedestal commitments and signature scheme? So on top of this on top of this we've built a I built a Pedestal commitments and signature scheme and at snacks have also implemented it So and Zcash are now using this in the wild. They've had it audited although their work is is a little bit different than ours because they use a different They do use a different Curve and that means that they're yeah, so their their work is not directly trans transferable But it's still like a proof of concept that this is possible Okay, so a big thanks to them and congratulations that I'm on their recent hard fork. It's cool Okay, so next we're gonna talk about we're gonna talk about scalability. So 20 minutes cool, okay, so next we're gonna talk about scalability so so far we've done So far Yeah, so so far we've just talked about using using snacks for privacy and now we're gonna talk about using snacks for scalability so we can So so the thing that we were missing was a signature scheme before before that We we weren't able to really use it for for privacy, but now we can or for scalability, but now we can So here's here's what we do we take the we take we make this new form as Proposed to before where we had we just had the private key be just this simple Two images that are to to this just secret key that we hashed together We got the public the public key we replace this now with with this new construction This is for this is for a generic database. Yeah, a permission database So in the tree we have a BNC and each a BNC has a public key associated with it as well as an object So the public key tells says says who is allowed to update this object? Yeah, and the object can be Whatever you want it to be it can be like a list of tweets. It can be your token balance. It can be a bunch of other things as well So this is like a generic Scalability solution where you can update these leaves in the Merkle tree in batches So I think I'm getting a bit ahead of myself Yeah, okay, so the way that this works is that we have a single prover Yeah, and we have a bunch of users and what the users do is they aggregate signatures together and No, what the users do is they make signatures and they pass it to the prover and the prover aggregates these signatures together and Use and makes a ZK snark to prove that they updated the Merkle tree correctly. So let's see how that looks. Oh, I should have Yeah, so this is what they do They have the old Merkle root then they have a snark where they prove that everything was done correctly That they where they validate a bunch of signatures and then they have the new Merkle root Yeah, and and there's proof is proof that they have possession of these that that's so so they so for example They can't update the tree. They can update and take someone's money unless they have a signature to send it somewhere So what the user does if they want to send if they want to update the leaf is that they sign a e E and B Yeah, and then our snark does the following things Okay, the snark checks that the signature matches the public key pub key here in B. Oh, yeah Yeah, checks that the signature matches pub key Generates the leaf B by hashing it with the object that that's that's that the the user probably also provided Checks that that leaf is in the in the tree and then replaces that leaf B with a new leaf E Okay So you see what happens you see what happens? You can go like this Yeah Okay, and what we do is we have a snark that proves that before we had we had root and now we have updated root So the so we use a smart contract to verify each transition and now the operator now we now we know We have a smart contract that validates each transition and now and now we have a system where the Where Sorry now now yeah, so this is just a general scalability system So we know and so now the operator isn't able to isn't able to update the tree unless the users allow them to unless the user Gives them a signature and says okay update my leaf a to be a to E. Yeah, so that makes that makes sense I mean, but this is this this really doesn't work as it is right because This really doesn't work as it is because it costs 500,000 gas to validate the snark Right and it costs like less than less than 10,000 gas to validate signature inside the snark inside the EVM So why would we use this? Does anyone have any ideas? okay, so so Batch Yes, batch them up because the verification of a snark is succinct. We can include as many as we want inside the snark Yeah, so basically instead of instead of using this for one single transaction. We use this for like 10,000 transactions Yeah, so we can aggregate together 10,000 transactions and we can and we can use this to update the merkle route So this is where we get our scalability benefit. Yeah, so now it takes five five hundred thousand gas five hundred thousand gas to validate 10,000 transactions, which is great. I mean, it's great We're moving things are getting cheaper. Okay, so so now So just to summarize to link the cryptographic so cryptography stuff to here So what we did before when we defined this twisted Edwards curve that we were using is that we we wanted to make a signature Scheme and we need to make a signature scheme so the users could sign something in the and the opera and the prover wasn't able to To sort of steal people's money and move things around So we made the signature scheme and now we just validate a bunch of signature schemes inside the snark and we Update our route. Yeah, old route new route Perfect. So we do that. So we do that a bunch of times inside the snark We have like a for loop and we end up with just a single proof that we had transition a to be correctly new routes to New route correctly Okay, so what are some problems with this? Okay So some problems with this is is the proving time. So the proving time is quite quite high I think you can prove on on on on like regular hardware to 20 million constraints And that's about enough for maybe 12 12 transactions but But that's not our limiting factor here. So because it turns out that we can use a AWS Amazon web services to do to bad sees or another cluster Yeah, just any cluster to bad sees transactions together and to make the proofs But this cost money, but it doesn't cost a lot of money It costs like one thousand two hundred dollars per proof Which is totally which is totally fine if you if you do one thousand two hundred dollars for ten thousand transactions It works every chip Yeah, okay, so and we can use Pedestrian commitments. It's difficult to have a hash function That's efficient inside the snark inside EVM, but that I should talk about that in a while Okay, so now our only problem becomes this our only problem is now the data availability problem Yeah, that we know that the operator can steal people's money But we but the operator is able to is able to block people from getting their money and does anybody know how they do this Yeah, okay Yeah, they refuse to publish it. Yeah, they refuse to put so so someone does a Merkel tree update Yeah, and then they refuse to update publish to people the Merkel leaves that they need to make the proof Yeah, and when you refuse to do that nobody is able to move their money anymore So now let's talk about sort of solutions to this. Oh, I'm almost done last time okay, so So one of the one of the ideas is this thing called roll up and roll back Yeah, so with roll up what you do is the the prover Continues to update the Merkel tree. They do these transitions and then and then and then we have this We have what we what it's called Yeah, so it's similar is similar to plasma exits and we can we cannot merge in split leaves It's just like it's just like plasma or cash I think where you have like these independent leaves and you can't join them together, but you can send them to other people Okay, so that's so one solution is roll up Yeah, which I'll talk about in the next slide and the other solution is to is to pass all the data from the EVM into the snack. Yeah, and Vitalik has a nice post about this and I'll talk about this in a little bit as well So so how does roll up roll back work and roll up? Oh, no roll up roll back. It's actually called snazma roll up roll back is the old name so So we have a priority queue. Okay, so so listen we have so the operator Aggregates everything's transactions and they and they go block at a time block at a time Moving forward with the chain and then at some point in the future Let's imagine that our operator becomes malicious and they refuse to publish the Merkle path or the Merkle leaves that you need in order to exit your coins So what do we do? So we have this thing called a priority queue a priority exit queue I'm basically anyone who enters a priority exit queue is able to is Anyone who enters that queue the operator must serve that queue within the timeout that we define like a week two weeks Something like that and if the operator doesn't doesn't doesn't fulfill that request What we do is we slash the operator and we say that okay data is now unavailable Yeah, and what we do is we start to we do two things now Yes And we start the rollback mechanism. So this is probably an excellent so rollback. Okay, so here's here's the current Here's let me set the stage. So we have the operator has been running for a while for five states Yeah, we started at s1 where the one person deposited one coin Yeah, and we know that data is completely available then then we move then we we we started to move forward The operator makes next proofs and validate them on chain and we ended up at state 5. Yeah, and at state 5 the operator refuses to share the data so At state 5 we enter the priority queue and the operator refuses to refuses to exit us So what we do is we start the operator and we have this kind of auction for a new operator Yeah, someone else to take over the chain And the when you bid in this auction what you have to do is you say you say the state that you want to begin from The state that you want to take over from so you don't have to continue from state 5 you can continue from any previous state So you say the state that you want to continue from and you say You say the state that you want to continue from and you say how much you want to put as your deposit Yeah, and we have like this idea of a limited deposit and something something like that That's fine. So so we finish the auction and we selected the bidder who selected the newest state with the highest The highest bid. Yeah, and then what do we do? Let's say that the new operator Yeah, so the idea is that the new operator will never will never Ask to continue from a state where they have all the data available to them from a state where they don't have all the data available Because they will be trivially slash immediately Yeah, and they'll lose all their their whole deposit So then let's say that they're up the new operator comes and they say, okay, I'm gonna take over at state 3 So what we what do we do? We have this transition from state 5 to state 3 So what we do is we say that okay anyone who has an in-flight transaction between state in state 4 or state 5 is able to exit Yeah, and we have another period where we have this kind of plasma style exit where people come forward and say Okay, I want to go I want to leave and that works out fine So so then we roll back to state 3 and the new operator continues Yeah, and If no, so if if no operator comes forward and says listen, I want to continue We just go all the way back to the state zero and that's just basically a plasma exit. It's more ordered though Yeah, what was I? Yeah Okay, so that kind of works, but it's it's kind of there's a bunch of problems with that one of the major problems is that you can't split and join leaves together for a reason that I can discuss afterwards and people have questions about it and another problem with that is Another problem with that is like this idea of finality that you you don't know that you you're not guaranteed that your state is not Going to change rollback But we can have this kind of weaker finality Assumptions and you can say that listen if I have all the data for a single for a single state I know that if there's a I know that someone will come forward to take over from another state Or I can come forward and take over from that state So people will know that okay. We want to roll back a little bit Okay, so that's that's kind of that's kind of how roll up roll back snazma. That's how snazma works Okay Okay, so now the other option is to do data availability inside the chain And what we do is we just pass all the variables from the EVM to the snark and we verify we very and this way no one is able to No one is able to We pass all of them. Yeah, this way the the data is definitely available. We rely on the theorems data availability guarantees Yeah, but this this is kind of this is not great for two reasons for some reasons. It's It costs a lot of gas per transaction Which is sort of limits our scaling not at the amount of proofs that we can make or the size of proofs that we can make but at the At the cost per transaction So we were limited by gas inside the EVM because we have to pay gas every transaction that we include Yeah Yeah, so I talk about compressing here But I sort of leave out the nuance of that but yeah, we have to compress the data to inside the EVM But compressing is just hashed together So that works that works too and this is kind of the approach that we've sort of moving forward with at the moment So this comparisons with plasma, which I already sort of did okay, and then I have two examples So this is like I let's finish I won't do the examples because because we only have like five minutes eight minutes left Yeah Five five six minutes left. Okay, so let's just talk about yeah, these two examples quickly So one is you can if the and this this was done at a hackathon in Berlin by a bunch of people And I would say their names when I'm not sure they want me to say their names, so I won't unless yeah, okay, so Yeah, so basically they did a not a non-fungible token with roll-up and it works pretty well and we also are Me and a few people are working on Making some sort of generic token with this where we can just batch token transfers together Yeah, each and if we were gonna use data available in your own chain as I said before and each Each leaf has a variable amount user can trade tokens for to each other, but not split. Oh, oh No users can split the tokens That's not right. That's slide And users can exit a leaf what the leaf is. No wait, that's not this slide as well Yeah, okay, sorry about that Okay, so let's talk about roll-up problems really quickly and then then we'll have some questions Okay So so one that one problem is that the proving time is quite big and we need to Outsource this as it's quite long. It takes okay So it takes about it takes one hour and a half to prove on AWS and it costs like $1,500 a little bit less than that And we want to reduce this and we think that we can reduce it, but it will get more expensive And then there's other ways to reduce it to instead of using the cluster We can use GPUs that PGA is an ASICs and those are all open open areas of Research that or of implementations that I'm interested into talking to people about if people are interested in doing that That's cool. Come in. We can talk about it Can we add strong anonymity properties to this system? That's another research question because everything okay everything is completely transparent here Just because we use a snark to aggregate the data doesn't mean that doesn't mean that we still have the anonymity properties that we had before So is it possible to add those anonymity properties back? That's another interesting question So we have optimizations. Yeah, so it's interesting. It's this at snark's projects have done a lot of work with With these these optimizations. This is move forward quite quite well Also, I did I then three have another implementation. It's not so working on implementation. I need three are working on implementation to Yeah, and we're gonna replace rat 256 with partisan commitments in some places. That's all that's all good. So future work Yeah, so we want to implement both approaches Yeah, so if someone if there's a if there's someone who's implemented interested in implementing the other approach the Snasma approach would be interested in that too So we're I'm interested in hearing about Other use cases other than just scaling and tokens or tokens and stuff like that I'd be interested to hear other use cases that we can use it to aggregate transactions together and aggregate like bolts and things together Though that comes with a bunch of problems still. Well, yeah, we could do that too Non-fungible token, maybe we can make an exchange with this Stacked request. So this is like a request. So it would be good to have the gas cost reduced in the EVM Newer curve for more security would be nice So we use all BM 128 right now and be nice to move to BLS the one that's he casual uses And that means we could reuse a bunch of their a bunch of their Signature schemes and stuff like that and a bunch of their tools and we could all just be working on the same curve That would be great And it would be good to have a hatch function pre-compiled that that's efficient inside the snark something like partisan commitments That would be cool. Okay, that's it Okay, thank you Okay, so do we have time for questions? Yeah, we have time for maybe one or two questions Okay, if people want to ask me more questions, I'll just hang out outside for a little while and we can talk Okay, so who has any questions? Yeah you mentioned one possible use case is Hydratic voting. Yeah, and I wonder if you have any like design ideas about how you can Ensure that someone doesn't Have create multiple identities in order to skew quadratic voting Okay, so there's like there's like some ideas about this one thing we could do is and it's a bit creepy as we could use like We could use biometrics in order to limit the amount of people who are able to join our group But this is this has problems too because people can just make fake biometrics. Yeah So we'd have to have some kind of real-world Biometric testing station and that's not really very I don't know that that has some problems It's game of all the other thing is that we could have a we could have this kind of these kind of Parties where everyone comes and you every every attendee is able to join the group but But that kind of limits us because every attendee You could just get your friends to come and take their take their keys or take their position in the group Another thing that we could do is we could have this like really high barrier to entry and say that you have to Have accomplished x y and z in order to join That's not very good either because I mean sort of limits the amount of people that can join and can be sort of commit to it So yeah, I mean it's sort of it's a difficult problem I think and it's but it's one that's important to sort of figure out and solve So I think a good approach would be to do like some sort of trusted hardware with with some sort of biometric Database or something like that. I mean it's it's not very it's not very nice But it could if we need to do something like that we could do that Yeah Yeah The white t-shirt he asked first and then you can is the stuff that stockware is working on could that potentially improve the Efficiency of this or is it completely different? So they would improve they would improve the proving time But they would improve the proving time, but currently the proofs are a little bit big And it's still I mean I'm totally interested in seeing what they have when when when they sort of when they're ready for that But it's still it's still moving forward. I guess it would be good to talk to ABU who's here He sort of has some more more ideas about that. Yeah, okay, cool. Sorry. That's my time I'm if anyone wants to talk I'll be outside. Yeah for like the next