Zero knowledge made simple | Justin Thaler

Transcript

[Music] thank you hi I'm really happy to be here get to know all of you um yeah so this talk is about zero knowledge proofs so I'm going to start with uh what what are they uh yeah so I thought I'd start with um so ish or ahead of um a community and social uh asked a bunch of us from the research and Engineering teams recently uh to explain uh zero knowledge proofs in one tweet to someone new to the web 3 space um and I thought I would start by mentioning some contexts which is that in the web 3 space in particular the term zero knowledge has been overloaded

so in a precise sense zero knowledge refers only to a certain privacy property okay but uh people often use the term especially in the web 3 space to refer also to uh performance properties of zero knowledge proof systems that many of them have uh happen to have okay so zero knowledge uh it's really a misnomer it should only refer to the Privacy property not to the performance properties so the tweets all had to sort of grapple with this uh so Sam Ragsdale tweets tweet was first so he said a zero knowledge proof mathematically demonstrates to a third party uh typically called the verifier that you've done a computation honestly without revealing the details nor requiring recomputation okay so that property not requiring

recomputation that is a performance property so that says the verifier is really fast okay so that and technically that's not what zero knowledge refers to um what zero knowledge does refer to is uh Sam's phrase not revealing the details okay um so in fact of course the you know if you're proving to somebody that you did a computation correctly that someone does have to know exactly what computation you're claiming to have done correctly because if you did even one step wrong your proof should be rejected right so when Sam says not revealing the details he doesn't mean the computation I'm claiming to have run is like not fully known to you no the

verifier knows the computation there are certain other details that zero knowledge says the proof will not reveal so we'll try to clarify that through the remaining tweets and then I have a whole presentation to clarify the issue okay so then Joe Bono uh colleague on the research team says ZK proofs are essential for web 3 because they allow us to ensure correctness while maintaining privacy for example we might prove that a financial transaction is genuine while not revealing who paid whom or how much okay so Joe is really focusing here on the Privacy aspect um I think for you know it's it's really hard in the Tweet so it might not be clear uh why it would be useful to show that a financial transaction is genuine without revealing who paid whom or how

much so hopefully I'll try to clarify that moving forward but now we're getting towards details of what what zero knowledge really means uh so what's being revealed and what's being hidden by the by the proof okay so so Lara uh who's speaking tomorrow my another colleague from the research team said ZK proofs and blockchains are typically used for statements like this I'm entitled to authorize action F because I hold a secret that satisfies requirements are without telling anybody the secret okay so this is actually very close to how I think about zero knowledge so the proper zero knowledge means uh the prover is proving to know some secret information he wants to prove he knows the information but he doesn't want to actually reveal anything about the

secret to the verifier other than of course that he knows it okay so then I was the final tweet um so I specifically sort of broke things up into this privacy aspect which the terms of our knowledge really refers to and the scalability or performance aspects which the terms of our knowledge does not actually refer to even though people use it uh to refer to both which is confusing okay so in terms of scalability uh the zero knowledge proofs often have the property that I can prove I did a hard computation on some data so the blockchain for example the verifier doesn't have to do the hard work itself or store the data okay so this is what Sam was getting at in the first tweet saying uh the verifying the proof doesn't require re-execution

is it saving the verifier work okay so scalability is all about using the zero knowledge proof to make the proof or do some hard work so the verifier doesn't have to do the hard work itself okay now we get to the Privacy property which is what zero knowledge really refers to um and the classic web3 application is I can prove I put some amount of money into a mixing pool without revealing the deposit transaction that was mine okay so the people taking the money out of the pool kind of can't be linked to you know which entity they were when putting the money in that's why it's called a mixing pool you kind of can't tell you can't link uh money going in the money going out okay

um so those are all four tweets uh but since I have a talk I can actually give you definitions um and I think it's useful to see both like the you know 180 characters or whatever it is version and then the the full slide and talk version um so I'm going to start with what is a zero knowledge proof in a slide um and we'll talk about what are people using them for today I'll tell you a little bit about how they perform today um and that'll be enough information to start um to understand the public discourse around zero knowledge proofs and how they're being deployed today which actually can be fairly challenging there's a lot of context that you know if you don't have it going in the conversation I think it's very confusing so that's one of the main goals I have

to sort of impart how to like the right context to understand the conversation as people discuss this technology and finally I'll give some predictions for the future um okay so let's start with the Talk version of what is a zero knowledge proof um and and snarks and I'll say what a snark is kind of a funny acronym snark is really referring to things like performance and zero knowledge is referring to privacy and people just lump everything together today as zero knowledge proofs which can get confusing okay so uh my first slide here is on the Zero knowledge the Privacy part and I like to explain um what zero knowledge means when I give a talk through an example um so imagine Alice uh controls some

Bitcoin wallet and wants to prove to Bob that she actually controls the wallet okay so the trivial way to prove this is she could reveal her private key to Bob think of the private key as like the password that to the wallet okay but then of course Bob controls the wallet too okay so this is like a totally valid proof that Alice controls the wallet but she doesn't want to use that proof okay so what is your knowledge proof we'll let Alice do is the exact same thing she'll convince Bob she controls the wallet but Bob will learn nothing about her password about her private key okay and that's what zero knowledge means you know Alice is claiming here to know a certain piece of secret

information we often call that piece of information the witness and a zero knowledge proof will convince somebody that Alice does know that secret but it revealed nothing about the secret other than that she knows it okay so that's zero knowledge now we'll talk about snarks uh which uh is an acronym referring to the performance of the proof system okay so now the idea is um uh say say you know uh Alice once again is proving to know some secret information okay uh and again the trivial proof system here would be to just send the secret information to Bob or to the verifier who can just directly check that the uh witness is valid you know it satisfies the property Alice is claiming

it does you know it actually is the password to the Bitcoin wallet or or something like that okay um so a snark uh which stands for succinct non-interactive argument of knowledge it just achieves the same effect of convincing the verifier that the prover knows the secret information uh but it's less expensive for the verifier okay so zero knowledge is about not leaking the secret information to the verifier and snarks are about saving the verifier time and communication relative to uh checking the secret information directly okay so snarks are on their own don't care whether the verifier winds up

learning stuff about the secret or not it's all about how how efficient is the verifier okay so succinct means that the proof should be short and typically it also means that they should be fast to check so at a minimum they should be shorter than just sending the entire witness to the verifier which is like kind of the trivial Baseline you know the prover can always just send the information to claims to know to the verifier um and ideally checking the validity of the snark proof will be significantly faster than just checking uh direct you know somebody if Alice actually sent her password you know checking that the password indeed controls the wallet in that example okay

um this is really important part of the talk to kind of stop and see if there are any questions um if there are uh the microphone would be great to use but does does this make sense does anyone want to ask them for clarification yeah I'll repeat the question yeah great okay so the question was what is the difference between zero knowledge proofs that I've described uh so far and public and private key encryption um and the question specifically I believe focused on an application where um if I want to prove to somebody that I possess a private key corresponding to a public key um then I can just sign a message

uh yeah so that would be um a example of a valid proof for that particular application it would be um so the application of you know I know the password to a Bitcoin wallet which is another way of saying I know private key corresponding to public key um is a very specific one where you don't need the full power of snarks um so the kind of the Revolution over the last 10 years in snark design has been in especially in obtaining efficient snarks that can prove any statement um and we'll we'll talk more about how like the workflow Works where you know you write a program that checks the witness and the approver uses the

program to kind of prove it correctly apply the program to a witness yeah so in in very particular applications such as the one you just asked about you don't need the full power of a general purpose snark you can tailor one specifically to that application they can be much simpler than there's another question I'll repeat the question so go ahead yeah yeah so the question is what is the witness W in general what data type what's an example um so it varies wildly by application um in this little example which I it's it's a real example but it's also um simple enough I could call it a toy it would be very useful uh W would just be the secret key it'd be Alice's secret key would be her password

um in something like what people call a ZK roll-up even though many of them are not actually zero knowledge um the witness would be a whole bunch of blockchain transactions Each of which has been signs to represent that they have been authorized by the owner of the wallet um yeah that the transaction is originating from um and you know in a you can go through application of your application and it's it's always just the prover's claiming to know some information and the witness is just that information so it's very hard to say oh it's like this data type you know it's a it's an array of integers it's an in cryptographic applications it's often you know just uh secret keys or I don't know uh 256 bytes or something often uh anyway so yeah

more questions the question was can I talk about the cost of snarks um at a high level the verification tends to be relatively cheap which is why we can run the snork verifier on a blockchain in many settings although there is significant variation in just how cheap the verifier can be so the bottleneck tends to be in uh proving cost bottleneck in terms of like how complicated a statement can we actually use a snark for today um and there are a lot of these costs that are relevant from runtime to memory usage um yeah I'll say much more about that soon uh yeah so uh and if if our snark is zero knowledge uh we should append the

letter ZK in to the front of snark to indicate that so A ZK snark is a zero knowledge one but a snark by itself doesn't have to be zero knowledge at all it can reveal information about the witness to the verifier okay uh yeah so let me just Briefly summarize things that snarks are used for today uh that I think they're going to be used for a lot more stuff in the future um so maybe the most prominent uh application today is uh L2 Roll-Ups validity Roll-Ups and uh I did mention this in response to one of the questions recently like here the ideas that um in order to keep uh both work and data off the blockchain

um you're going to try to kind of keep as many transactions as possible on an L2 Layer Two um and the layer 2 will prove to the layer one blockchain like ethereum that uh you know the uh a bunch of you know signs valid transactions uh were processed on the layer two um and the layer one blockchain will kind of not have to directly process those transactions itself and this is important because uh any data that we store on the layer one blockchain or any work that the layer on blockchain does well that has to be replicated over and over again by every every blockchain node in the world for that layer one so we're kind of just treating the layer one as a very sort of limited

computation limited verifier that we much rather just kind of ver have verified proofs that the layer 2 correctly process transactions rather than have the layer one blockchain actually verify all the transactions directly yeah um and I'll say more about this soon um so we're also now seeing the emergence of bridges between blockchains based on snark technology um you start proving things like you know uh the you prove to the bridge or the bridge proofs to the blockchain like I I correctly ran a like client uh for blockchain one um you know that locked a bunch of funds uh so now it's okay to uh sort of use those funds on the other blockchain

something like that um and so there are a lot of bridges that do not use snarks but we're starting to see more and more bridges that do um okay we also see privacy focused blockchains um so yeah even though the validity Roll-Ups from two slides ago are often called ZK Roll-Ups um the ones I put on that slide are not today ZK they're not privacy focused um so on this slide we have just a small sampling of um projects that are privacy focused uh so the idea is that people can transact on the blockchain um and if you if you don't use zero knowledge proofs today it's essentially like just having your entire bank

account public for the whole world to see uh it might be pseudonymous where you know it's not your government get you know given name um associated with your account um but it's known that it's not too difficult to link real world entities to these accounts and so it really is like just having your entire blockchain public for the whole world to see every time you transact um so with the the zero knowledge proofs you can still manage to transact while keeping a lot of your personal information secret essentially um okay so in a little bit bigger picture I think eventually these um snarks ZK or otherwise will start to become public infrastructure the way

today's encryption algorithms are um so just as today's public key encryption algorithms were once like state-of-the-art cryptography um that you know enabled uh the e-commerce Revolution um snarks are just very Advanced cryptography and eventually it'll just be sort of old hat the way um you go on to Amazon today and buy something and you don't think about it the cryptography just works um in fact a lot of vendors who are it's not just the users of these e-commerce e-commerce sites who don't know anything about cryptography a lot of the vendors also don't have cryptographers on staff uh everything just works it's public infrastructure essentially and there are

obviously companies in the ecosystem that are making money somehow off of this I'm sure uh but uh everything just works no one no one really thinks about it no one has to know the details of you know just how performative the encryption algorithm is um you know is it really secure no one has to think about that I I don't think we're there today with snarks but I think we'll eventually get there um so yeah I think the the issues today are these things are just not performative enough quite yet and they're not easy enough to use use that I think any any startup in the space should know something about these uh I think the two key things to try to learn a little bit about are their performance so you have a sense of you know if you

want to use a snark like what is reasonable to try to use it for and what isn't today and unfortunately I think you should also know about their security so I'll say a little bit about that as well okay um so just as a quick checklist for like when you definitely should care about snarks um and even if you don't meet any uh elements of this checklist I think it doesn't hurt to to know something about them anyway but uh if you care about privacy for your users um or you want lower transaction fees uh both relative to just posting raw transactions to L1 you're gonna need to know something about snarks if nothing else you're going to need to know like what ZK roll up to use if you're privacy focused that really means EK roll up in

the precise sense and if you only care about scalability I you know I mean validity roll up um and uh probably at some point most startups in the space that are active on the blockchain there are transactions uh will care about at least one of these two things um now these Snorks are also essentially just getting built into the blockchain infrastructure okay so if you care about the blockchain infrastructure um you're going to have to know a little bit about snarks for that reason so for example as Bridges cross train Bridges start to get built based on snarks which we're starting to see now uh if you want to move assets between blockchains you should probably know a little bit about

how these Bridges work and also ethereum itself with uh upcoming eips are going to build at least some components of some snarks into the base layer itself so in proto-dank sharding there's something called kzg commitments which a lot of snark shoes not all snarks and protodank charting will use these kcg commitments for something called Data availability sampling the details I guess aren't super important for this talk but perhaps you've heard that ethereum itself is sort of running a massive trusted setup with thousands of participants over several months and this is what they're using it for so they're trying to kind

of allow they call them blobs like more data to get kind of posted on chain and that creates issues that they are then trying to address uh using some components of snarks um at the base layer right so uh you know it's the same sort of thing that I mentioned before about how eventually this will all be public infrastructure no it's like when you use the internet you don't need to know how TCP works okay but um you are using it every day and these snarks or components of them are actually getting built into like the internet of web 3 namely the base layer L1 blockchains okay and then finally there a lot of

businesses will just want to use snarks just for because of the idiosyncrasies of their business I mean just as one example and I'll give more later um yeah I mean anything that involves off-chain computation by untrusted parties so I think um over time you know every day we see new advances in Ai and it's becoming clear and clearer that it's going to transform Society in unpredictable ways and right now uh those models and the ability to train those models are gated by a handful of entities and I think one of the um you know use cases of web3 that at least excites me is uh to uh kind of ungate these resources that will be clearly uh essential to society and

cause significant disruption moving forward uh you know like the the entities that currently control this infrastructure uh they you know are subject to their own incentives you know the public you know does not control their decisions and they might be acting in entirely good faith but they just have different incentives than everyone else so just as an example in that in that application the whole point is um that uh of a lot of hard computation is going to be done that's the whole point of cloud computing um and in a decentralized world um you don't actually trust whoever is doing that Computing even if it's you know your idle GPU on your laptop um so that's just a setting where like

it's very clear like a lot of difficult computation is going to be done by entities we don't trust but would like to work with right so these snarks are going to be essential for allowing uh people who don't trust each other to work together anyway especially when a lot of hard computations getting done okay so I think there are tons of reasons uh everyone should care about snarks at least a little bit to know uh at least about a one hour presentation's worth uh so that'll be my goal today is just to try to convey what I think every startup in the space should know so let me start with just ballpark uh sense of how these things perform today with the main goal being to know kind of what would be reasonable to try to use a

snark for today and what wouldn't be um okay so so generally as I previously mentioned the verifier is cheap in particular significantly cheaper than kind of the trivial verifier that would directly take the witness the prover claims to know and check it for correctness so that's good right like um these snarks are just completely useless if verification is not cheaper than the trivial approach so that's good as I mentioned before there is still significant variation in the cost of snark verifiers so for example uh plonk proofs when verified on ethereum today cost about 300 000 guests and another kind of um snark proof called Starks they take 11 million gas

today this is a bit of a moving Target because the uh security level of the proof systems has been increasing and for some of them that causes the gas cost to go up and for others it doesn't really um so in terms of applicability in general the bottleneck tends to be the prover performance and my rule of thumb is uh that the prover today in general is always going to be um you know uh at least six orders of magnitude slower than uh just directly checking a witness for validity okay now for particular applications it can be way less than that for like very structured um you know like correctness checks uh it you know this million fold slowdown

for the prover um to actually prove that it did something correctly uh won't come up well it won't be that bad at least but in general if you don't you know tell me anything about the statement that prover is going to claim um you're going to have to factor in at least a million fold Slowdown and one nice thing about this million fold slowdown is it's entirely paralyzable so you can just like throw gpus at it and if you have enough gpus it'll eat up that entire million fold overhead but you did just pay a million times more total work so at some point um you know depending on how ambitious you are in terms of the statement you're asking the prover to prove that 10 to the sixth slow down is untenable

right like um fortunately in a lot of blockchain applications like Roll-Ups the statements the prover is proving are in a cosmic sense pretty simple I mean they can still kind of push the limits of what we can handle today um but you know proving I know a bunch of valid blockchain transactions that have all been authorized with digital signatures is ultimately a pretty simple statement right like proving like you know I ran this uh cloud computing computation that would have cost fifty dollars to run on Amazon because it killed a cluster for an hour or something I mean that's another thing entirely it's just night and day okay so this million fold slowdown like you can't just ignore like while snarks have come a long way in their performance in the last 10 years or so you can't just

ignore it and say oh we're there uh it's not even close to that okay um and there are endless more subtle you know in the weeds issues especially as you compare different snarks to each other in terms of their security properties and like Ken you have the prover like produce a bunch of proofs but not post every individual proof to the L1 and rather just aggregate the proofs down into a single proof so you can you know spend many many years studying this stuff and still not have it all clear in your head like you know there there's so many different things people care about and axes on which to compare these protocols um but this slide kind of covers the high points in terms of approver time and verifier time okay uh yeah so uh there's a lot more

details about um the performance characteristics of snarks uh in in this a16z blog post um which we can distribute if and if there's interest in that um yeah uh okay so uh I want to now give a sense of just how snarks work I often get the question hey I want to use a snark I don't know anything about them though like how do I get up and running with a snark and that's really a question about just what is the existing tooling today um and so I'm going to tell you a little bit about how to think about that tooling um and both its strengths and limitations okay before I tell you about the tooling I want to tell you um how I like to think about snark design and this is a little bit aspirational of

what I'm about to tell you because the tooling isn't quite there yet today there's no fundamental thing keeping the tooling from achieving this but aspirationally we'd like a developer to start by writing a computer program in a high level language whatever they like rust C python who cares um and this computer program you should think of as taking as input the witness that the prover is claiming to know and checking that the witness is correct okay so in this simple example about that I had before about Alice claims to control a Bitcoin wallet this computer program would take as input her password her private key and check that indeed the private key

control is the wallet okay uh now uh in order to use a snark um to you know for the prover to prove that it knows this witness uh kind of the the development process would proceed in two steps and ideally the following two steps would be hidden from the developer right the developer just writes the computer program and and the developers done okay so the first step is these snarks need to use something called an intermediate representation it's kind of just like a very very low level way of expressing the computer program so you have to take the computer program written in a very high level language which is nice to program in and turn it into like kind of the world's lowest level language it's kind of like even

lower level than the assembly code on your laptop or something um so this is some something called a circuit or generalizations of circuits uh we just call them intermediate representations in general and that procedure to go from the computer program written in say rust or python or something to the circuit is called a front end okay and in general there's already a lot of performance overhead just in kind of that step because the circuits are like a pretty awkward way to represent a computation um you know your laptop um has a bunch of native instructions built in that it can do in like one step one machine step that are pretty gross to rep to do inside a circuit the kinds of circuits we use in snarks

um and then after you kind of identify the circuit uh you apply what's called a back end to the circuit and that allows the prover to prove basically that it correctly evaluated the circuit on the witness and because the circuit was equivalent to the computer program like evaluating the circuit on the witness is equivalent to running the computer program on the witness and the computer program its whole point was to check that the witness satisfied the properties the approver claimed it did so you sort of put these two steps together and you have your snark so the pro you know together the prover is proving hey I know this witness that this computer program would have accepted as valid the the snark is kind of the combination

of the front end that spits out the circuit and the back end that proves the prover like evaluated the circuit correctly right so you have your your rust program the front end spits out the circuit the back end allows the prover to prove that it actually like knows that what we call a satisfying assignment to the circuit any questions oh yeah question so the question was uh sort of what um if the dev only writes the high level program uh kind of what's handling the front end and the back end I guess yeah and the idea is that that will ultimately um just be a completely automated process uh you know like these eke VMS today may be a little um easier application to talk about um they want the developers to just write smart contracts uh and if ZK EVMS

want it in you know solidity or something like that um other projects will have their own domain-specific languages and that that's you know that's it then the sort of the company or the you know has developed the infrastructure to apply the front end and then feed the resulting circuit through a back end and then um the smart contract like the roll up smart contract on L1 will be running just the verifier um to verify the kind of the back end proof yeah so just a brief summary of existing tooling if you are a developer so that there's the question of um how are you going to express your witness checking program and what language are you going to express it in and

um kind of once I tell you that um everything else is ideally hidden from the developer now again today the tooling is maybe not uh perfectly there where um the front end and the back end just you know the developer just doesn't worry about them at all they're they're really nice libraries that kind of make things as easy as they've been able to today but there's definitely room for improvement so but in terms of like how do people write their witness checking programs um so very popular uh but very low level languages for this are Bellman and circom um so when people tell me today hey like I want to deploy a snark um you know I want to use ethereum um and I don't want to you know go you

know write a smart contract on a L2 or something like you know I just want to deploy a a a snark directly on ethereum or something like that I say well can you write in a circum circuit no Can you hire someone who can right so um yeah people really like writing and Bellman and circum but it's almost like writing the circuit uh kind of gate by gate so it's almost like not a front end I don't want to get too you know overboard in terms of how low level uh these uh languages are but they're pretty low level it's like you you have to be comfortable kind of almost directly programming a circuit a bunch of projects have kind of higher level languages but still assembly like so definitely lower level than probably

what anyone in the room is used to programming in unless you're already designing snarks yourselves um so a prominent example here is Cairo from starkware so this is an assembly like programming language um that I I hear is like a really nice experience to write in um but again it's a much lower level uh language than so I rust or python or something and there are also like snark specific issues that the programmer in some of these languages needs to be aware of for example um these snarks all use something called a finite field so if you like multiply a bunch of numbers together and the number just gets too big the number will kind of wrap around like an overflow issue and the programmer for Cairo I believe

today still just needs to be aware of that like that tracking that is pushed onto the programmer for example um and there are steps and this is where I think um things will get better quickly towards letting developers program in even higher level languages I just mentioned one project um which uh is nice is is risk zero is a project that is aiming basically to be a front end for something called the risk five instruction set which is a instruction set that actually came from the computer architecture Community was not developed by cryptographers or anything and there's a large um kind of ecosystem today of tooling to turn higher level programs into risk five programs and once you do that you

can the idea is you could then feed the risk 5 program through risk zero uh we'll handle the remaining kind of front-end and back-end work and of course all the zkuvm projects like they want to let the developer just write in solidity like ethereum developers are comfortable with today and not worry about um how the front end and the back end are working so I think there's there's nothing fundamental standing in the way of the tooling supporting higher level languages that people are more used to than these new domain-specific languages like Cairo and Leo and Noir but it's not there today okay any questions about this okay the question is are you trying to distill um what gets um kind of presented to the

L1 down to kind of the minimum possible information just to keep that information and work off L1 uh there I'd say Yes um you're you're basically trying to prove to the L1 that you did something uh that something is always like just processed a bunch of blockchain transactions um correctly um and all that the L1 cares about is like confirming that you did that it doesn't actually care like what was in the transactions um just that you handled everything right um so yeah the the that's what the proofs are showing is just that uh all of those transactions you know were

checked correctly and like applied you know to advance the state of the blockchain correctly um and the proof itself um you know it doesn't inherently need to contain any information about those transactions uh now there's a big discussion to be had about um you know uh data availability and which is if you're not posting the raw transactions or at least the State updates to the blockchain you know um anyone in the world who wants to be able to transact does need access to that data um so where does that data live and you know people are either storing that today in what what's called call data which is like semi on chain um but they're also trying to move to things like data availability committees that will keep the data completely chain

but the proof itself if we ignore data availability the proof can contain like basically no information at all in fact if it's zero knowledge that's the whole point it shouldn't contain any information other than uh you know I processed a bunch of transactions correctly and it kind of advanced the state of the blockchain from A to B and like let's not worry about you know where the information about what even is State B uh gets gets stored in the zkevm does the witness include the computation itself so the term witness refers to uh the data that the prover is claiming to know uh checking the data is where any like hard work to check that that data is correct would kind of reside um so you know I always think in

circuits it's on designing these I'm like in the weeds designing the snarks it's like the the witness is the secret information but the circuit itself is kind of um like extra work the circuit does is like just as bad for the snark prover as like making the witness bigger like for this for the snark prover like witness elements and like circuit gates are treated typically close to the same and very there are some exceptions um yeah so the question is uh I think the answer to your question is just like work rather than data like should you call that part of the witness or not I would say it's it's not part of the witness but it does it all contributes to the prover's work and that's really the scalability bottleneck for these

snarks okay so that's sort of a snapshot of the tooling ecosystem today and again I think it's going to get real better real fast um and if you're interested in how the back end of these snarks work and that's kind of where all the magic happens um I hopefully spitting out a blog post soon about that that will kind of be you know uh my attempt at if you have 15 minutes to read and you want to know you know how where how all the magic happens uh that'll be the goal so I'll make sure to distribute that once it's finally finally ready uh yeah but this uh I wanted in this talk I didn't want to focus into like some very very deep dive into exactly how uh snarks work but more just how to how they perform and how to navigate the public discussion around

them um which is what I think is really important for startups in the space that might either directly use these snarks or be a customer of a company that is using these Snorks or something like that okay so now I want to talk about um how to navigate the public discussion I think you now have enough context to uh I can discuss some of the subtle issues and I I sort of started looking carefully at the public discussion around snark's in web 3 last summer uh when I was visiting a16z and it was it was just very hard to understand like what people were talking about so I want to make it a little easier for everyone else and also just kind of flag some things to be aware of um some kind of you know things that can

trip people up I think okay so let's start with these validity Roll-Ups these ZK Roll-Ups um with the discussion around their performance okay so this was something that confused me a lot at the start so I saw a bunch of these l2s talking about processing thousands of transactions per second even 20 000 transactions per second and this did not make sense to me because I know roughly how fast these provers are and the prover unless I think with any reasonable computation resources is not chewing through 20 000 transactions per second so I asked some of the projects and uh the answer I got was this is refer this is just not

counting prover time this is only counting uh the time it takes to upload a proof to the L1 okay um so in a little more detail uh there are two performance Notions that I think are really important for a roll-up uh this is latency and throughput okay so latency is like the delay between when a transaction happens on the L2 and want to prove kind of capturing that transaction gets verified on L1 it's like a lag time okay and their approver time does matter right because if it takes the prover a week to produce that proof that's a week of latency okay other another big contributor to latency today uh which might contribute much much less in the future is just

waiting around for uh enough transactions to happen on the L2 that is kind of the L2 is ready to start working on a proof there are a couple ways to deal with this so one is just to get a lot more transactions on the L2 so these batches are filling up really quickly another way is to use some other kinds of snarks that can kind of start working on the proof even before all the transactions are there which I actually think uh the technology will move towards that um soon I I'm a proponent of that this is something called incrementally verifiable computation which is not really a focus but anyway so yeah two contributors to latency um but throughput is talking about the the number of L2 transactions that can be processed in a given amount of time

by the Roll-Up it's a little subtle how these differ so I think when these projects are talking about you know processing thousands of transactions per second okay the idea is you know that uh there kind of would be continuously uploading proofs to the L1 okay and uh so you know it might take a while uh from when a transaction hits the L2 to one a proof capturing that transaction gets is is done being produced but through pipelining you can ensure that proofs are kind of continuously getting uploaded in steady state this is not happening today this is kind of the vision for the future um so as far as throughput goes uh prover time is not that important okay

what's important is just like how many transactions each proof is covering and like how long does it take the proof to get uploaded to L1 right so yeah so this I mean I I found this uh just kind of deeply confusing um to start so I think it's worth clarifying that um and it does make sense like if you're talking about throughput and you're in the steady state situation um throughput is really determined by just the the uh how quickly can proof data get get uploaded to L1 okay but again if these proofs take a long time to produce uh the latency will be high okay so transaction per second is a measure of throughput and it does not refer to latency at all

and there's actually kind of a direct tension between them because the larger you allow the latency to be the bigger you can let the batches of transactions be because it's going to take the prover kind of longer to prove those batches but you don't care because we're letting the latency be high but the proof size the whole point of snarks is the proof size grows very very slowly with the statement being proven the complicatedness of the statement being proven so um yeah the bigger the transactions because these verification costs are kind of very very sublinear the better the throughput the worse the latency all right so now I want to talk about security considerations so here's a

quote from a document that an organization called um the ZK proof um okay so this is a kind of a community organization involving developers and researchers you know interested in the zero knowledge proof technology um interested ultimately in developing some standards um so that it's a little easier to kind of compare proof systems and make them interoperate with each other and things like that and there's a reference document that this community has produced and it does have a quote about security that I want to share it basically says uh if you eat just benchmarking a snark like in a paper or something to understand its performance you should have the security level set

to at least something called 128 bits actually says ideally you go higher than that I'll say a little bit in a second 128 bits of security means but it's just a measure of how secure is the snark okay uh this is not what the snark Community is deploying their snarks at today not not all of them anyway so for example uh stockware today with its uh Stark x d y d x rollup is at 80 bits of security now I'll tell you exactly what that means it means that there's a known attack that if it if it performs two to the X hash evaluations and if you don't know what a hash evaluation is don't worry about it will succeed in producing a convincing proof of any false statement with probability about 2 to

the minus 80 plus X so just to make that a little more clear 2 to the 70 hash evaluations will get you success probability about one over a thousand two to the 80 will get you success probability pretty close to one now the um that that is a hundred trillion times faster getting success probability pretty close to one then the ZK proof Community reference document says should be achievable okay and in fact um if you if you look at how many hashes the Bitcoin Network as a whole does it does two to the 80 hashes in under an hour and the number the amount of block rewards in US dollar values for that less than an hour of hashing is well under a million dollars okay I mean

they're they're using uh there's been enormous investment in afix for Bitcoin hashing um that there hasn't been for the hash functions used to protect these snarks uh these Roll-Ups but that just gives you a sense I mean the point is 80 bits of security in my opinion is not enough and the community has actually uh deployed snarks at that security level for several years now um so I've been talking about this since last summer and uh I'm actually really pleased stockware has upped their other roll up there they call it the the Stark net and or sharproofer from 80 to 96 bits which is much better but today I think dydx has over 300 million dollars of total value locked it's still at 80

bits of security a lot of the other projects that are using similar approved systems they're around 100 bits which is you know that basically means the known attacks are not feasible but if slightly better attacks were identified it would it wouldn't take that big an improvement over the known attacks to be back in a worrisome situation so uh I've been trying to kind of encourage the community to up the security level this is all in terms of known attacks okay so now I want to finish talking about um oh yeah so here's just a tweet uh Stark we're saying they're going from 80 to 96 bits uh in their in their sharp their uh Stark net uh uh roll up um now I want to talk about bugs so security flaws that the protocol

designers are not aware of okay so these snarks they're complicated um and that's why it's taken several years to develop these eke uvms there's a lot of engineering involved you know I've looked at the code bases it's not pleasant there's a lot of like security critical code that's not commented and if you know uh so periodically vulnerabilities are found this is not unexpected I just want to highlight a couple um so Trello bits found an issue in a number of libraries that believe had been deployed um last year this was an issue with something called the fiatrimir transformation what that is is an importance what is important is

this was a known issue that has arisen over and over again over the years um it affected something called the Helios proving system I think like 10 years ago and then some voting system that a country had deployed I forget which country had the same issue so in my opinion protocol designer should have been aware of this it was known and library after Library had exactly this issue I mean and I think the issue might have stemmed from some academic papers you know the academics are writing a paper and they're not expecting you know somebody to protect you know a billion dollars of assets with you know the little cold box they put in their paper and like one person looked at but that kind of what might have happened here um okay here is another vulnerability

this is actually in the tornado Cash Smart contract the main thing I want to highlight here is the vulnerability was actually in this circon Library so people really like writing circuits writing their front ends in circom and this was some issue in the library okay so the point being that if the security bug is in some library that everyone's using everyone says okay so actually vitalik gave a talk at um one of the recent ethereum conferences definitely in the last six months in Colombia uh he basically suggested that uh we should be deploying snarks uh we shouldn't just deploy one we should deploy two or more the reason being that he's sufficiently concerned that these will just have bugs

and the bugs will just mean that they're totally insecure that we should you know kind of have two or more so that you have to get kind of doubly unlucky or you know break both um but my personal opinion is going back to the circum bug you know that's a library everyone uses okay so these two snar implementations are not likely to be totally independent of each other so this might not actually help that much and there is another recent proposal um that suggested just using trusted Hardware in addition to snarks as sort of a Band-Aid until we're actually confident that the snarks are bug free uh so I'm just I I don't want to you know like weigh in on what you know what I think about these ideas I just want to

highlight like the ethereum foundation itself is you know very aware that these are complicated code bases and likely to be buggy for a while and suggesting concrete steps to take as a result as a result I think anyone who is using those code bases even as a customer even if you're not interacting directly with them unfortunately needs to be aware of this situation uh moving forward it affects everyone um so that's just context that I wanted to cover um and yeah I just briefly mentioned coming back to the question before about security um yeah you know directly comparing the security of different snarks is kind of impossible in the sense that I mean you have to just list out all of the security assumptions right so

um some snarks you know do not have a trusted setup which means there's not some complicated uh people call it a ceremony but um where many different participants each kind of contribute to uh the um generation of what's called a proving key structure reference string and uh if all of those participants kind of got together and um they could like reconstruct some secret and then uh kind of produce convincing proofs of false statements for it forever and ever um so so trusted setups like are a security issue but you know if you if you're like ethereum and you run a trusted setup with 300 000 participants I mean I I don't believe that all three hundred thousand people are going to get

together and reconstruct the secret and go and like you know counterfeit um you know Z cash or something um moving forward I mentioned Z cash crust they had an issue with a trusted setup previously that would have allowed that um yeah but uh yeah on the other hand uh you know and then then the trusted setup snarks I'll use elliptic curves um so if you manage to break an elliptic curve based crypto system you would break those snarks um but we don't know how to do that today I mean all the cryptography everyone uses today is based on elliptic curves we have to Once quantum computers come around which might be another several decades we'll have to switch from that uh because quantum computers can break elliptic curve cryptography um

on the other hand the snarks that avoid trusted setups and avoid elliptic curve cryptography are getting deployed sometimes at a level where they're breakable today so it's just a very you know saying oh one is more secure than the other is it's a very difficult conversation to have personally I am most concerned with known attacks today and having a little bit of wiggle room so that if those attacks improve a little bit but there's not some like you know complete break of the protocol that they're still secure that's my personal view um on how the conversation should kind of be framed most productively so the systems that I've been a little bit critical of um they're uh do essentially due to their avoidance of elliptic curve cryptography which in general is is good

you know because eventually we have to get rid of the curve cryptography um they have this property that um the more secure you the more bits of security you want the bigger the proofs have to get which means the bigger the gas costs okay it doesn't really affect the prover time it affects verification time now it gets a little more complicated as today people are using what's called snark recursion or snark composition which um sort of starts to intermingle like verification time improving time let's not get into that so that's really the trade-off so um when I gave a presentation this summer um that the 80 bits of security snark was at um about 5 million gas per proof and I was looking at the 96 bit of security

version last night it's up to like 11 million gas but not all of that is attributable to the security increase I think other things about the system must have changed too so really the gas costs just should have increased roughly 30 percent ish due to security and then the rest must be just because other things are changing about the proof system so that's really the tension in a nutshell is verification costs versus security level for that class of snarks does that make sense other questions okay so the question is what is the name of the known vulnerability so this is something that comes up anytime you use something called the fiatrimir transformation which is a way to take an

interactive protocol and make it non-interactive so like the snark proof can just get posted on the blockchain for anyone to check out their Leisure um it's and the n in snark means non-interactive um and yeah if you know anything about the fiatrimir transformation it all involves hashing and essentially anything that might be under the control of the adversary needs to be hashed and these proof systems were not hashing everything that might be under the control of the adversary um in particular they were probably not hashing some I don't know for sure but it's probably some analog of the statement being proven something like that um so if the if the adversary can choose

the statement being proven the adversary could come up with some statements and convincing proof for that statement now the statement might look like gibberish but it's still like a false statement that it has a convincing proof for so yeah it's it's so it's kind of a weird sort of bug where you can have the bug and not necessarily get totally owned but it's still you don't want the adversary to produce convincing proofs of false statements even if the statement that is finding convincing priests for is like kind of a nonsensical statement it's still not something you want to be running the risk of so somewhere on the slide I think it has um something about random Forge proofs for random statements yeah so they weren't hashing the statement being proven so

um the adversary could kind of mess with the statement being proven to find like a false statement and a proof for it but the statement is just like a weird random statement it's nonetheless uh not a vulnerability we want in the system um yeah so people will call uh weak fiatrimir versus strong fiatrimir that's that's what to look at all right so yeah let's talk about uh future applications of snarks um so I'm not a particularly creative person so I can I'm really just going to tell you like things I've heard discussed as possible applications with snarks that would be exciting so I I've already discussed kind of decentralized cloud computing which I am personally excited about I think it's not great for society that um kind of the resources that are gonna underlie kind of the

coming AI Revolution or whatever are kind of currently gated by a handful of giant private companies um so I think that um using snarks you know you could have the whole world be a cloud computer and you know kind of produce a snark proof that all of the work it was hired to do it's actually doing it correctly as you go um in a similar vein because a lot of what people use cloud computing for today is machine learning um I think uh people there's now a buzz phrase zkml ZK machine learning so I think that will become much more efficient very quickly uh kind of by exploiting special structure in the statements that are relevant to machine learning this could unlock things like letting smart contracts

make decisions based on data that is on chain and so like their decisions might actually change over time as the blockchain evolves also just using the blockchain to perform learning in public um so that I this gets really powerful if you start having uh if people start signing their data okay because then you can prove you know uh Hey like I trained up this model on some data set I'm not going to tell you what the data set is but I can prove to you that every piece of data in the data set was signed by some entity that's reasonably trustworthy so you can kind of get privacy and learning happening at the same time so I think getting people to sign their data is uh really powerful

unlock for zero knowledge in a lot of settings but especially learning settings um okay you can also Imagine um private Biometrics to access accounts or establish identity and also I mean in in Estonia I believe the government just issues digital ID cards right and then anyone could presumably go around and prove they're over 18 because they hold an ID card and they can prove in zero knowledge that you know their ID card has been signed um and you know uh the message that was signed is some birth date that's more than 18 years ago or something like that so digital identity is obviously a potentially impactful uh application um that obviously does require potentially buy-in from

um you know an authority to issue credentials to people um okay we've seen um there's like a paper from 2015 on fast but untrusted Hardware here in this paper anyway the idea was there's there's only like four countries in the world that have state-of-the-art foundries and so any other country might not want to run security critical applications on a state-of-the-art chip because they didn't have control of its manufacturing could be deck to order something so you could instead um you could have the fast chip run the fast run the computation quickly and actually prove it did it correctly you just have to run the verifier on a trip you trust so if the chip is much slower it's okay because it's just the verification being done there

um we're going to have a lot of issues with deep fake detection so people have been looking at like basically you know cameras signing images and then people proving that they obtained you know some image by editing a signed image and you know in an authorized way or something like that um and we'll just see the injection of privacy into things where privacy is not today so um I mean electronic money obviously to today um would have you post your whole bank account publicly to the blockchain right so we talked about how you can use mixing pools and things to potentially avoid that um and of course my personal view this shouldn't be surprising is um the situation with blockchains today is vastly less private than kind of the the

web 2 situation uh because even though the web 2 situation does have all sorts of you know like all sorts of transactions are getting reported regularly to the government and what have you at least your whole bank account is in public so I think without um using zero knowledge uh to change the State of Affairs we sort of have an even much worse privacy situation today as we move towards uh distributed blockchains then we uh do um with the with the centralized ecosystem um yeah and uh I'm again I'm not very creative I just just kind of design these protocols so I think there's all sorts of unlocks that are going to happen in the future yeah and really interesting stuff to discuss uh if any Yeah question them

back so the question is can I elaborate on getting data signed um so today there are already some devices that will just sign everything they produce particularly with digital cameras but there I forget what they call it um authenticated sensors or something it's um uh the idea is you know uh with internet of things or something we're just going to have all these sensors all around and maybe they'll be signing signing the data they produce the idea is like some chip is getting like grafted onto the sensor um and so it's very difficult to tamper with the chip once it's there and then like the manufacturer should be throwing away like the uh like the secret key as soon as it sticks the chip on the sensor

and in this way you get some amount of confidence that um you know the data coming off the sensor was really produced by the sensor um but in general you know the the it doesn't have to be sensors signing things it could be you know just some institution that people think reasonably highly of and that has a reputation they want to protect um you know taking responsibility and want to you know either puts out data sets or you know gives data sets to its customers or something they're signed and then anyone who has that data can prove that they ran whatever computation they want on some data set that's been signed and what this avoids is the following um situation so like let's say I you know I ran a giant ml model on

some giant data set and I want to preview I did everything correctly okay but you don't know the data set we have a problem now because I can make up data right so you can build into the analysis like some sanity checks like if it's height data you can make sure no one is 10 feet tall right so you can build Insanity checks but if the data isn't signed it's still like how do you know that it's like real data um if it is signs you know that who's ever signature is there authorize the data so like it's uh legitimacy is sort of pushed on to um whoever you know whoever signed it without any signing um there's really nothing to stop somebody from making up data other than simple sanity checks to make sure it looks okay

yeah so maybe there's uh I'd be very excited if anyone wants to talk about future applications because again I mostly just listen to them and then repeat them um yeah I'm not uh I work at like you know in the weeds of Designing the snarks not how they're used okay so just wrapping up here I can make some um predictions for the future so in terms of um performance like let me just sort of remind you that today I think in general there's a six order of magnitude or more slow down for the prover compared to just checking a witness with no proof of correctness okay so I think this is going to come down I am optimistic about that I actually think that um maybe three of those orders of magnitude might disappear fairly soon I think maybe one

might come from sort of better front ends meaning smaller circuits uh one one another motor magnitude might come from better back ends meaning once you tell me what the circuit is the proof will just get faster to produce for that circuit and then I think there's maybe another word of magnitude or more from specialized hardware and so forth Just building up better engineered systems and things like that um I do think that the techniques that achieve this this is my very personal view are not necessarily the techniques that people are deploying today okay so um I think people were going to have to remain flexible uh both you know the companies deploying the snarks and any of their customers you know just should be prepared also uh for the you know

transitional pains I think um uh no one should get too invested in a particular way of doing things today because yeah I think it'll change um another major bottleneck for the prover today is just space requirements and this thing I very briefly mentioned before called IVC incrementally verifiable computation I'm very optimistic we'll um not not only let you do things like start processing a a batch of data before the whole batch is is sort of in um but we'll it also should significantly reduce the approver memory requirements which actually is one of the big one of the big bottlenecks today even more than improver time um yeah so I think performance improvements are coming I think uh it's

you know it's going to be a bit of an engineering challenge if if they come from techniques that differ significantly from what people are doing today uh also I think that a lot of the bottlenecks in what people are doing today like the in Roll-Ups that are keeping the signatures off chain to so that you know they don't have to pay the gas costs of putting those signatures on chain and verifying them one chain I think the probably the bottleneck for the prover is just proving knowledge of digital signatures which means you don't necessarily need like a completely general purpose snark to improve that substantial the current bottleneck you can just have a snark that's very specific to proving knowledge of digital signatures so I think we're going to see major improvements on that front kind of more specialized kind of gadgets for the things people are doing today that are

the bottleneck um and they can sort of be added on to think of it as an Asic or like a coprocessor that's helping out a general purpose CPU um so the things that are the bottlenecks kind of are handled by the special purpose stuff but it doesn't restrict the generality of the whole thing because you have a general purpose CPU as well um I actually think that as Society moves to post Quantum secure cryptography and like the National Institute of Standards and technology is trying to decide today they're about to run a second competition for uh deciding what post Quantum cryptography to use because a bunch of finalists from the first competition got broken like within months of the competition ending um Lara will talk some about that

tomorrow um I would actually like to see Society kind of consider the snark ability of The Primitives especially the signature schemes as they decide what to switch to this stuff is very sticky and once you sort of say we're going to switch to this it's like very hard to change that decision um this is a probably a tough case to make because uh you know um proving knowledge of digital signatures right now mainly just comes up in like ZK Roll-Ups right it's like uh most of society is not convinced that um that is an essential application to have in mind as you make major decisions about what cryptography to use but I think it is something that should be considered um yeah so just some commentary there

then finally this is my last my last slide um I think that these things will get much more usable very soon I think the tooling has some gaps in it today and it's not because of Any fundamental technical issues that need to be solved it's just we need more Builders um we need more people who understand snarks and hopefully they can make it the case that no one else in the world has to understand the snarks um so I think this is uh we will see the ability of developers to program in high level languages that they're used to already rather than learning domain specific languages that a lot of projects have developed I don't know how good the performance will be right away but I'm optimistic it'll it'll get there I think that in general these major like

Herculean efforts of you know like the zkvm projects for example which has taken multiple years to implement the snarks as they need them I think that effort for those experts will also get much less where maybe you could build a new zkevm in a matter of months instead of years and eventually less than and so forth um and I think you know along the way they're going to be security issues just bugs and you know the community sort of coming to a consensus about what is an appropriate security level and things like that until we reach that stage I think everyone unfortunately does have to have some awareness of these security issues that I try to discuss today um okay so that's everything I had to say thank you and let me know if your

questions quick question for you what do you see the roles of nanson like the the data platform for Traders and dune sort of playing in the role of CK Tech um so maybe I don't know enough about the trading platforms to fully understand are you asking will will snarks sort of change how people do trading either like more of the transparency on the data okay well to see more accurately what's happening on chain yeah there's a level of uh anonymity that comes with CK Tech yeah um I'd say so what what ZK unlocks generally is sort of scalability and

privacy okay so in terms of um I think that they will clearly change how trading is done on chain um because uh you know you don't have the same experience um with on-chain trading today as you do in like a brokerage account some centralized thing right order books and blah blah um and so so clearly and the reason is scalability issues and the as snarks get more and more performative um we'll be able to move all of that stuff off chain and have it prove to the chain so certainly the the trading experience is going to change just for that reason something transparency um you know you run into just like the

data availability issues um with all the Roll-Ups it's like the the gas savings from Roll-Ups is likely capped at maybe 100x or something if you're storing all the data on chain and maybe that 100x I can't keep track of it almost so fast with the various eips like that you know Proto dank sharding the whole point is kind of to make things um cheaper for Roll-Ups um and so maybe you know just by sort of declaring things to be cheaper that moves the 100x to without I don't know to a thousand X um but you know the real unlock is if people find a way to keep that data off chain um and yeah uh the question is just uh the data does need to be available and

uh you can sort of brick the whole system if it's not and so if you keep it with like five entities is that really better than you know the current situation today of a handful of Brokers or something like that so that's an ongoing problem that has nothing really to do with snarks is that what you were asking were you asking about something totally different no I mean that that partly answers it I guess like there's a bunch of like C cool developers on Dune querying the blockchain right and creating really cool dashboards from the ability of everything being so transparent and so so available oh I see and you sort of talked about how like right now we just have our bank accounts on chain and everybody can see that but it seems like there's a new world coming

yeah yeah it's a great question about um you know is privacy in tension with transparency um I don't have great answers to this you know um I think so one thing I think is clear is is privacy is not fundamentally in tension with something like compliance and probably transparency can something similar can be said about that you know for these dashboards and things like that um so the idea with privacy and compliance would be um you know you you prove that a bunch of transactions um are consistent with some uh you know government mandated compliance policy but you reveal nothing about the

transactions other than their compliance right so you're reeling sort of like just a bit the technical challenge here is you know bid is compliant or not compliant the technical challenge here is to express the compliance policies in it has to be in like as precise a form as imaginable like a circuit that sort of takes the transactions as input and checks that they're compliant right or any computer program um and probably this is yeah I mean probably you can say something similar about um the sorts of data analysis things that you're asking about but that's vague and I just really need to know more about what the dashboards are showing totally yeah cool thank you yeah thanks for the question

yes thanks for the talk um I have two questions actually so one is um as you mentioned the approving opens up attack service that in libraries Etc right so like since vitalik's proposal you think is not effective uh what do you think are the alternative for that yeah it's a great question uh like what what do we do like can we use these until we're confident that they're not buggy um how do we know that they're not buggy if we don't basically create a bug Bounty for them by deploying them and letting people see you know um I don't have strong thoughts I mean I think that uh Justin Drake's sgx proposal is a reasonable Band-Aid um

yeah it's uh it's just very hard to hard to say I mean it's like uh like any new security critical technology is hard to work out the The Kinks um but if if you look at these code bases it's it there's a lot of code it's complicated uh that's not super well commented um yeah it's it's there's not a good answer I think there there just will be some breaks hopefully most of them are identified by white hats before black hats and um and Band-Aids in the meantime are good I guess yeah it's a tough question okay and my second question is like my from my understanding optimistic roll-offs

mostly costs come from call data storage right and then CK mostly come from validity proof so generative so which one do you think the cost will decrease faster what like what does the curve look like yeah so I don't have a great prediction for this uh especially uh you know I I you know I I really am the expert on just the snarks I'm not sure it's necessarily the case um that the bottleneck for gas costs for the validity Roll-Ups is today is already uh is the proof checking um so so if you're using like a plan proof today I'd say that's definitely not the case because it's under 300K gas for proof

um so already the bottlenecks might be coming from all the call data already in which case my understanding is the the validity Roll-Ups need less call data yeah because they can kind of uh you know kind of gross up transactions in a way that you can't if you want to support fraud proofs um yeah I mean I I think we're all we might already be at the case where it's it's you know you should be really looking at call data versus call data uh for the for on the gas cost front um and then the other thing to look at obviously is like proofer bottlenecks on the on kind of the latency front or just you know the the cost uh that today is not public when the approvers are centralized of just you know how how

expensive is it to uh run the prover um yeah okay got it yeah thank you yeah thanks for your question hey earlier you talked about ungating AI I just organized uh AI for good hackathon and I was wondering how could you use snarks for either accessing or really using models on chain yeah um so using models I think is is pretty clear where um every time you need the model to perform inference on like a new uh piece of data you know to make a prediction about that data or make a decision based on it um you wouldn't have the blockchain

like you know evaluate the model on the piece of data you'd have someone do it off chain and prove they did it correctly to the blockchain um the you know and in terms of performance like you know uh training is significantly harder than inference but I'm optimistic we'll even be able to like prove to the blockchain we train this stuff correctly on then you run into the issue is the data signed or if it's not signed how you know it was like you know legit data or something which I already discussed um but in general I think these issues uh will be solved ultimately um yeah the the other question was the accessing accessing yeah yeah I mean so we we're seeing efforts now where um you

know the goal is to kind of um have a heterogeneous decentralized mass of compute Hardware you know you could just like kind of sign your GPU up or something your personal GPU but no one's going to trust that you know when you say hey I ran your workload correctly um you know pay me pay me a dollar because here's the answer no you know you're going to want that dollar um if you can get it without actually using your GPU that's better than having to run your GPU together right so we're going to need proofs that uh the answer returned uh by this decentralized mass of compute Hardware are correct and the hope is that the snarks just get performative enough on the prover end

that that's doable and I'm not optimistic for a completely general purpose thing but I think the the really key stuff that is you know just as I think like proving knowledge of digital signatures will get much better in that today a bottleneck for all the projects trying to keep the signatures off chain I think most of you know the unlock of this stuff is like training up models and all the models are today doing roughly the same thing and so you can specialize your snark to that and I think it gets much uh much more believable that you could actually produce a snark proof that you you did you did everything correctly gosh does that make sense yeah yeah thanks yeah

hey Justin thanks for the talk uh on the front end side of things so either today with like surcom and like really low level representations for like computational like logic or something in the future where it is like python or rust like is there a fundamental disconnect between like a user or somebody writing this like Circa representation for logic and like you knowing that that logic represents what you want to prove if that makes sense so it's almost like by having to codify this in some representation it's like the user's burden to have a correct representation for what they're trying to prove like for simple things I'm sure it's not an issue but as logic gets complicated no yeah so I think that um this is a major concern um so I haven't um dove into the weeds of you know like the zkevms now but uh like the special

but uh a bunch of the snarks uh the the Roll-Ups when they were just handling transfers and nfts I did look closely at that and you know they basically had like literally tens of thousands of lines of code of like Bellman or circum uh expressing these circuits like highly optimized circuits they needed presumably the optimizations for performance reasons and I mean I think it's uh almost impossible to believe that there's not like somewhere in you know you give me all those projects each one with 20 000 lines and yes there's overlap that there's not a bug anywhere in there and one little bug all of a sudden you know like the tornado cash situation uh bug you can actually

exploit the contract maybe was that was that what you were asking yeah so I guess like given that is there like how do you respond to that because like as even for like moderately complex logic this just sounds like it gets really terrible really fast yeah no it's a it's a big challenge I think I'd say two things um I'd say formal verification can do it's very free time intensive I understand to um formally verify the correctness of things especially these like circuit satisfiability instances which are kind of like a weird programming model because they take it like non-deterministic advice inputs the details aren't that important but I think you can do that um but uh I think the way you you I don't think you wanna I don't want I hope we don't live in a

world where you know some developer has to hand code a circuit for performance reasons every time they tweak what they want to prove and then like go through formal verification excuse me all over again I hope we wind up in a world where there's like a general purpose front end um maybe something that looks like Risk zero um you know that can kind of handle any you know uh program for a reasonable instruction set architecture right uh that front end gets formally verified you know that the circuits it spits out match exactly the program you feed into it right and then you apply a back end to the Circuit that comes out of that front end that back end has also been formally verified that it like matches some spec

and their security proof has that you know I think I think eventually that is going to happen and I think until it does happen uh there will be bugs to be honest you know I think it has to happen thank you all right thanks David um question uh on like a float Point arithmetics especially when it comes to Let's imagine in like doing like an inference uh proven inference in machine learning and how big of a bottleneck that is for example yeah um so it's it's a great question um I so I I am told that a lot of um machine learning models that actually just for performance reasons forget

about snarks like just to like train the model they're at least the expensive parts of the model are already often done at um kind of low Precision arithmetic even as low as like eight bits eight bits integer arithmetic um that sort of thing plays very nicely with snarks for sure um it's Knox work over these finite fields and sort of you you don't run into any like overflow or mismatch to choose um if you're dealing with like 8-bit integer arithmetic um and yeah I think that even going up to like uh certainly 32 32-bit floating point would be great and um I I'm excited about some work that I I'm just not yet ready to talk about today which

I think will make something like that much nicer is the short version uh today dealing with like 32-bit floating point would would be especially according to like an IEEE standard you don't want to like mess with how floating point is implemented or something like that it would it wouldn't it would be a performance nightmare uh but I think it's when I was saying you know I can see an order of magnitude here and here and here coming off like sometime soon I think those same techniques will also make floating points stuff nicer yeah are you referring to when you don't need to prove that you have run the specification and just prove like that no actually um prove it uh okay I'll just mention I'll just mention it it's unpublished work but I'm excited uh so

um there's something called lookup tables that are popular in snark design it it's especially helpful for um uh you know certain things are like not nice to do in a circuit like your your laptop can do them in one step and in a circuit it takes you know hundreds of Gates or more or something like that and you can sometimes uh make that less nasty by using what's called a lookup table uh the details aren't that important and um I'm working on some better lookup arguments which I think uh will really unlock um more uses of the tables it'll it'll let uh let us use much bigger lookup tables um which which is sort of what you need to handle

um some of these operations like 32-bit floating points okay thank you yeah so a lot of uh really nasty performance bottlenecks today I think will get better but the techniques to achieve them I think are going to be different than what people are doing today and so projects should be ready for those techniques to change yeah okay thanks so much yep [Applause] [Music] thank you