ZPrize: Making Real-Time ZK Proofs a Reality | Neil & Tony |

[Music] so hi everyone um I'm Nile emart and I'm with snarfy and this is Tony and he's with inyama and today we're going to be covering some of information about realtime proving so we're guessing that a bunch of people in the audience haven't had a lot of experience with zero knowledge so we thought we'd dedicate the first couple slides and just give a bit of a Layman's overview of what zero knowledge proving is all about so it turns out there's two main uh categories of Zer knowledge proving there's a circuit based approach and there's a virtual machine based approach the this slide shows a circuit based approach and um you can kind of think of it like like this there's a grid of cells and those cells all have equations in them so the first thing that happens is you take some inputs and you fill it into a bunch of the cells um the then you can kind of think of it a bit like a spreadsheet there's a computation that's done to um compute each of the values for the various cells and then there are several cells that are uh actually tagged as outputs so after the proof is done you're basically given back the outputs and what's called a proof receip and the idea of a proof receipt is that um it's a small piece of data that you can send to to another program called a verifier and the verifier will tell you yeah this uh this proof was done in accordance with all of the rules of the the grid and all of the equations were followed um you either get a thumbs up or a thumbs down the second approach is um zero knowledge uh virtual machines and this is slightly different so here what happens is somebody writes a program that program gets compiled to a set of risk five instructions and then the risk five instructions plus the input is fed into um the the proving machine once the proving machine has been initialized it basically runs through all of the instructions one by one and as it does each instruction it adds rows to the various tables there's kind of like a whole bunch of tables off to the side and finally when the virtual machine finishes then the proving system goes on to prove each one of those tables and it just like before you get um the output from the program plus uh excuse me plus uh a proof receipt and the proof receipt um if it checks out it tells you that um all of the steps in your program were followed exactly correct but there's one subtl subtlety here um you can have a bug in your program right so let's say your program wants to compute Pi to 10 digits the bug might cause your program to compute pi to 20 digits um or or sorry 2 * pi and you'll still get a valid um proof receipt um it's just proving that the bugs were run correctly so so there's a distinction between like the correct the desired result of the program and a correct execution of the program the proof re gives you correct execution okay next to formalize this a little bit like I've been saying there are two big pieces of software you have aover and you have a verifier theover takes um a program or a circuit a public input and a private input and it outputs some information and uh a proof receipt on the other side we have a verifier which takes the same program the public input and the proof receip but importantly it doesn't require the private input the verifier can do its work without knowing any of the private inputs that were provided to the to the Prov side and um the verifier will give you either like a thumbs up or thumbs down saying that um the proof was correctly executed and there are a couple of properties that I think are important uh all of this stuff relies on a lot of cryptography and some and a lot of math kind of under the covers but you get some fantastic properties out of that um in general the proof receipt is really small it's just a couple of kilobytes um um and uh and on the verifier side um you can typically uh verify a proof in a fraction of a second so even if you had a program in the VM that ran for five minutes you can still verify it in a snap um I guess and there's one last point to make here the prover is very expensive to compute right so not only is there a lot of math it takes a lot of computation to actually generate a proof okay there are a few pros and cons for uh circuit based and uh VM based on the circuit based side they tend to be a lot harder to um to design and to verify for uh security um whereas on the the VM base side you get um you know it's a lot easier to use you just have to write a program um but also on the VM Bas side it tends to be a little bit less efficient than uh than things that are done with circuits circuits are computationally the fastest um and and I guess a final note is that on the the VM side um you you get this nice property that the program execution can be broken into chunks these are typically called shards and um and those can be proven in parallel so um so the VM based stuff is a lot easier to paralyze okay now let me turn it over to Tony hi everyone I'm Tony from inyama um so so just to uh continue on with um the talk um so there are three broad uh categories of Engineering in ZK um first we have the proof system design aspect and this is where the cryptographers uh and mathematicians come into play um they're responsible for uh creating like the fundamental protocols and um um making sure that the mathematical uh proofs the zero knowledge aspects are secure and trustworthy um there are many many many protocols out there um the second category is the um application developers and they kind of take these proof systems and actually build some useful applications um on top of that um to fill some role um and then there are like the proof system optimization and implementation aspect um where uh optimizers like me and I um come in and uh implement the proof systems and protocols um for specific hardware and Hyper optimize them for performance yeah and this is what we do so um in in the zase base it's all based on a whole bunch of math from um a bunch of different branches of of mathematics like group Theory um linear algebra number Theory um and involving objects like um pols over finite fields and altic curves over finite fields and some of the important algorithms um that we use very commonly is these things called number theoretic transforms NTS um multiscalar multiplication msms there are other um uh other algorithms as well like Fast read Solomon IOP I and some Che um but the point is that it's uh really complicated and these algorithms are quite expensive to compute and uh one or two years back um this all run on um CPUs and it could take uh tens of minutes to generate uh a a mediumsized proof um and this is way too long to be considered real time so here we are in 2025 and and if we were still using CPUs for proving we'd still be not real time so we need to accelerate the computation with um some extra hardware and these we call accelerators so accelerators are kind of um cars that we can plug in to a computer or server um to lend extra horsepower um to the computer and there are kind of three categories that um we may talk about today one is gpus which are um essentially think uh a really really um if if a CPU was um had only a few cores that were very fast cores then a GPU would be um a device with many many many cores but each core is sort of slower um so it's great for parallel computation another accelerator is fjs so instead of um thinking of these things as having cores we uh kind of think of these as kind of a blank slate uh where you can't a a hardware designer can design custom hardware for their specific Pro problem like think custom instructions um Custom Custom arithmetic and finally we have as6 which are actually um uh hardened manufactured uh chips spe that are specialized for a particular problem so um one of the things we wanted to talk about today is the uh zprice competition which is um a competition that was um uh started to um uh it was a competition to uh to started to Accel uh promote the acceleration of um Z knowledge proofs and uh last year um the problem uh was to construct a plunk style ZK proof of um sort of a mediumsized uh circuit um and the actual problem was to generate an end to-end proof of a Merkle tree using the Poseidon hash and um on the BLS 12381 field um basically we had to run a bat of four Pro for and we used um two different accelerators the Nvidia uh a6000 and AMD 250 fpga um and uh for the Z prise We R our our GPU submission one the first place um however there was in sufficient time for us to comp complete the full fbj implementation however however we will show some um numbers in our presentation so uh in terms of uh the performance breakdown um our GPU solution um achieved 0.5 5 Seconds uh for a medium size proof remember uh we said that um CPUs for this type of problem took tens of minutes um and our fpj uh solution took uh 5.65 seconds which is still much much faster than a CPU um and here we can see uh the the breakdown of different operations in the proof um and uh so 2024 last year was a great for year for enter improving on accelerators um and we showed this with our uh Z price Mission achieving sub one second proving on the GPU and um which translate to a really really low cost per proof uh 01 cents per proof uh I'll hand it back to Nile now for the rest okay so now let's talk about uh what's next for 2025 so um last year uh Justin Drake he introduced this idea of beam chain so the the main thought here is that what we can do is is zkf or snark ify the um the consensus layer of ethereum so the idea that every time an ethereum block goes out um a bunch of people would generate snark proofs for the whole ethereum block and those blocks be could be committed back back to the uh to the chain and that would um allow much faster validation of the block because like we were saying you can check uh ZK proof in a fraction of a second rather than having to work your way all the way through the block so the state of the art today like right now is that it takes approximately 600 million risk five instructions to prove a a block that's almost full and um the the the current cost for that runs to about 6 cents uh per block proof now the one thing that's a little bit unfortunate is that the state-of-the-art right now today is that it's about 40 seconds of latency between when you start a block proof and when the block proof is completed as a as a snark and so that doesn't uh meet the requirement of Under 12 seconds uh for the generation time for ethereum blocks so a couple of months ago um snarfy announced that we will have uh real time meaning less than 12 seconds uh block proving by the end of June um so there's a QR code here if you want to follow along we'll be making announcements on this QR code okay and let me give a also a shout out for uh eth proofs. org this is part of the beam chain project and essentially this is a website where all of the companies that are interested in doing ZK block proving um can submit proofs of blocks right so they can run their their VM they get a a a time and a cost they can submit those to uh eth proofs. org and you guys as users can kind of watch the progress towards realtime proving so this is some information from eth proofs.

org just yesterday and um yeah you know just keep an eye on this space I guess I should say one other thing about about this um it's really nice to have a a standardized uh Benchmark for all of the ZK VMS um to compete on so I think I think you'll actually be able to see which which VMS are really performant and which ones are really actually cheap okay and um this is next to our last slide if there's one thing you take away from this talk I hope it's this um real time proving of medium size circuits is is really dirt cheap and it's widely available today um as an example uh inyama makes a library called icicle and you could use icicle today to build um to build this kind of of real-time proof for like I said mediumsized circuits on the ZK VM side um proving of large circuits and large blocks I guess large programs um is already really cheap it's like 6 cents for for a big program with a lot of computation um and in the near future in 2025 it will be broadly uh available as as a real-time solution um so I think the the closing comment I want to make is uh zkp has really arrived um it's now time to start uh developing interesting applications and deploying them and I want to turn it over to Tony for a last thought okay so this last slide is a kind of a a research topic topic uh open question um so uh this is a little bit more technical than the rest of the talk so during our um work on uh implementing zero knowledge proof systems uh we noted we noticed some Trends so that we would like to share so um for Bitcoin uh for Bitcoin mining specifically there was kind of like a pro progression from using CPUs then to gpus then to fjs then to as6 and kind of each step in this progression um there was like a huge increase in performance going from CPUs to gpus um going from gpus to fbj and Asic so you can actually see this in kind of like the the uh Bitcoin total hash rate that you can see it jump dramatically whenever there was like the first implementation on um the respective uh Hardware accelerator um but for current uh Zig proof systems we think that this progression is not going to look the same uh at least uh from what we see currently so um in our work we see that large portions of the proof computation like the NTT for example are memory bound and what that means is that um we cannot read uh the data from external memory fast enough to feed our comp uh our compute course so as6 um when when you build a custom chip for example uh to accelerate some finite field arithmetic um they have a potential for Far Far More compute than corresponding gpus however the issue is that as6 will not dramatically have more bandwidth uh more memory bandwidth than what's available already on uh consumer grade gpus so this extra computing power that will be unlocked by going to as6 could go to waste so it's that so this is a really um interesting questions and has big imp uh implications um for as6 designs uh that will be that may um be coming soon in the future and um it's been suggested that a large cache on A6 can alleviate this um memory bandwidth issue however uh we would like to uh suggest that this may not be the Magic Bullet that will save um that that will dramatically solve this problem um because for most proof systems um it's organized in rounds such that you can't start the next round without hashing the result from the previous round so you would have to kind of keep rereading um large parts of um large parts of the proof so this is a open uh res question and um we would like to uh write a detailed blog post about this so stay tuned uh so thank you um please follow us on Twitter both uh ingonyama and SFI um thank you thanks very much thank you