How zkSNARKs Can Provide Value: An Example with ZEXE

Transcript

uh thank you for coming to this talk i want to show you a bit about how we can derive value from snarks there's been a lot of discussion about snarks and well everywhere about providing privacy and attacking other problems i want to do this with an example which is called sexy so just to check we're all on the same page about what this is we're in the realm of verifiable computation right so how do you check that a computer program was run correctly we need this in a blockchain in order for it to function bitcoin does it ethereum does it but now we've learned to do it better

the way it's done in ethereum is if you want to check if a computation is correct you just redo the computation right if you get the same results you know it's done correctly so but with zk snarks we can add more valuable properties the first valuable property is uh verifying is exponentially quicker so imagine somebody gives you a sudoku and they tell you that they know the answer and you want to check their answer the way you would check isn't to get the starting sudoku work it all out yourself

and compare right that's all completely redundant you can do it exponentially quicker by just using the rules and we have this in a snark the second main point is the data is also exponentially smaller in the sudoku example the person doesn't send you the result they send you every logical step they used they say there's a one in this box and that box in this box in that box so when you line it up a one could only go here all these steps all that data that you don't need so the data is exponentially smaller and you have zero knowledge

um this doesn't really work in the sudoku example because you can prove you know the answer to the sudoku without showing it right so you get data privacy however you don't get functional privacy you can prove to me that you know the solution to a sudoku but i you have to tell me that it's a sudoku that you're solving it's not some generic statement you know it's not a cross word it's not anything else it's a sudoku but i can't see your answer so we do this with a snark and the question now is how do we use a snark so it's just a fundamental building block with certain properties the same as like wood

wood what is valuable to us not inherently about what we can do with it you can build a house you can build a table you can burn it you can do different things and you'll derive different value so the different teams using snarks are trying to achieve different things they may be trying to tackle some of the same problems but ultimately there's a lot of different value and now when you're applying a tool to derive more value there's some implicit implication of a limitation right it's not a problem per se

but uh we just find a protocol and it's limited within its box you can't do things outside of this box but with a snark we can start reaching outside and doing new things the first limitation that we want to try and tackle is scalability so the chain sizes are growing quite a lot ethereum over a terabyte bitcoin over 350 gigabytes and it's kind of sustainable but it is still a big barrier and it seems like we don't have to do this right there are ways around it it's also higher gas cost per transaction

because you're not putting a small proof on chain you're putting the entire computation a lot more gas cost the fundamental aim of this was to check the computation was correct right but we can do this in a better way now with a snark the second main limitation is privacy so most chains are pseudonymous by default but we're there's mounting evidence that pseudonymity doesn't provide the privacy that we thought many many cases of ways around this and linking people together and our digital footprint is growing we've got data about us everywhere

online now take whatsapp for example i used to think that because my message was encrypted it was fine no one could read my stuff or learn about me but what do people keep telling us about communication and meaning that only about five percent of meaning is from the words 25 is how you say something how loud your tone of voice your pitch these kind of things 70 is your body language so if we only encrypt the words what about the rest of the data

all the metadata you know whatsapp knows the model of your phone how expensive it was the language your time zone when you bought the phone because you logged into whatsapp immediately how often you change your phone it can work out your rough socioeconomic background it knows how many people you message it knows how long your messages are it sees when you message someone the frequency like if you're messaging the same person every evening late into the night you're probably in love with them they can tell if you're single or seeing someone or married potentially for having an affair so there's all this data out there and if you cared about your message being

encrypted in the first place you probably care somewhat about all the other stuff too now we have an assumption in the blockchain space many other places as well and this is that if you want to make something happen you don't need to employ somebody to do it all you need is an economic incentive we don't employ people to to mine blocks we just say hey if you do minor block we'll give you a reward so if somebody can go online scrape all your metadata process it

and sell it off to the highest bidder by our own assumptions someone's going to do it and it feels like maybe we should just remove the incentive make it impossible make it private by default the third limitation is uh application run time on ethereum in practice computations can only go on chain if they're at most 100 milliseconds this is mainly the gas cost and limit now but even if you didn't have those limits computation is tied to the state so on ethereum if you if your

computation takes 60 seconds the next block can't be made for at least 60 seconds and if you want 20 second block times you know these kind of computations aren't possible right so we limit the types of computations we can put on chain we limit the programmability there's two main ways to deal with these limitations the first is to augment the layer one i don't mean change the underlying protocol i mean add snarks on top to help tackle it now building a successful and functional layer one is really hard and it makes a lot of sense that we should go down this

route and see what we can do but we should also take the other route too and see how fruitful that is and at elio we took a first principles approach and we decided that it made more sense for us to build a layer one around a snark at it have a snark at its heart not to add it on top but to make full use of it so sexy was developed zero knowledge execution environment howard wu here is our founder and ceo project is also a co-founder and works on our team and we try to implement this and i'll show you a little bit about how

it works there's a lot on this slide but the main idea that i want you to understand is fairly straightforward you do your computation off chain you make a proof of your computation send the proof to the network the miners validate it and if it's valid they chuck it on chain compute off chain verify on jane now how do we prevent a double spend in order to do this we had to use a utxo model like bitcoin this record k is like a coin from bitcoin

in my computation i'll take this record i will prove that it does exist it's a valid record i'll do my transaction apply my function get out a new record and this is a transaction now we make a proof of this transaction now inside record k there is an id only i can see it because i have the view key because the record is mine i will deterministically make a serial id from that id i'll publish the serial id in the proof for everyone to see now i send the proof to the network and if it's valid it gets put on chain

with the record in the future if i want to use record k again in my transaction i have to deterministically make a serial id from record k gonna get the same serial id in this new transaction i send it to the network and the miners will see it see the serial id and say hey we've seen this serial id before it's on a blacklist we're not adding your transaction to the chain so we prevent a double spend and this design helps tackle each of these limitations

limitation one the scalability putting proofs on chain much much smaller a lot less data more space per block fairly straightforward how we tackle this the privacy um i said that you don't get functional privacy from snarks by default but we used a one layer recursion of snarks in our protocol to also give us functional privacy so you won't even see what happened whether it was an nft transfer or certain application being used or anything like that we get data privacy um so like just because a protocol uses a snark doesn't mean they necessarily get data privacy

right if you take ethereum as it is and replace the on-chain transaction with a proof you can get the scalability but how do you prevent a double spend how do you update the state if you can't see what's happening and you can't in their model so you would have to publish the data and you wouldn't get the privacy if you want to check whether a protocol has data privacy just go to their block explorer or whatever they have and look at a transaction and see what you can see and that will tell you exactly the amount of privacy so private by default

but if you want you can publish a view key to see the data and you might want this for certain applications it needs to be a possibility and now limitation three because we compute off chain and the proof is logarithmically smaller you can run your computation for a minute an hour a day a week as long as you like and chuck it on chain feasibly and this opens up a new paradigm for computations that can go on chain one of the main areas is ai processing and having on-chain ai things but this

is still an area that we're innovating in and we're trying to bring on people to understand what's now possible with these building blocks there is a consequence to this design or any uh protocol using snarks and that's that if you uh want to use a snark you need to create proofs so we need developers to know how to make proofs and the the the first solution to this the naive solution is just teach people how to make proofs but it's like a lot of work like you've got to do some cryptography and all this kind of stuff and it takes ages it would make more sense to go down the other route where you turn developers

code into circuits so this is why we created leo it's a circuit language it's designed to be similar to javascript and rust so that it's easy to learn very easy for a programmer to figure out um how to code in it there's if the screen works there should be a shot of the leo playground which is where you can go to a website in the bottom left the url and see how the language works and then it's formally verified like rust to help reduce developing times and it compiles to the circuit it makes the circuit for you it makes the proof it makes the verifying key and you can

deploy stuff very easily so it's designed to be as frictionless as possible and now we're at the point of trying to get innovation from functionality we've built a system where you have remove the scalability issues we have the privacy you can have long-term computation and we have to explain this to people so that more intelligent people come in and say now that this is possible we can apply it to this real world problem and derive real world value and i say from functionality because in order to do this you don't need to know how a snark works right how many people know how the

internet works or wi-fi they don't need to know that in order to derive value using the internet or wi-fi right all you need to know about snarks is a functional understanding we know what we can do with the internet to learn what you can do with a snark longer computations it's cheaper privacy when you want it cool thank you