Ethproofs Call #2: Real-time proving

Transcript

Ethproofs Provers Introduction

Hello and welcome to Eve Proof's call number two. This is a extremely uh special call for various reasons. It's a little bit of a celebratory call uh because of the the recent events. It's also a record call in terms of of number of participants. We have 140 people live now and then and and folks are are trickling in. We actually maxed out the number of invitees on the Google calendar invite. Uh and uh Zoom only has support for uh at least the subscription that we have only has support for 300 people. So let's see uh how that goes.

Uh we have 25 uh speakers today and it's going to be absolutely packed with alpha and announcements and and some some some fun stuff. So let me uh briefly uh share a few slides and then we can get started with presentations. Okay. So um there if you're in interested in continuing the discussion there is uh a telegram group which is public um e-proofs uh community and yeah today's goal as I mentioned is going to be dedicated to to real-time proving in addition the website eroofs.org or is fully open source and

uh has been from day one. And if you'd like to contribute uh please submit issues if you find bugs or even better submit uh pull requests. So uh this is the uh call schedule for 2025. Uh we are on call number two where the first call was dedicated to ZKVMs. We had about 25 ZKVMs introduce themselves. Um, and yeah, this call is on on real-time improving. The next four calls are going to be very exciting in my opinion. Uh, call three is going to basically try and explain how we could potentially get to 1 gigs per second on the L1 using ZKVMs.

Calls four and five are paired together. They're basically trying to answer what ISA should we enshrine, if any, within DL1. We're going to have proponents of risk five uh go first and then um suggesters of alternatives of risk 5 u come uh after that and then call six very very important security and formal verification. Now today's agenda is so packed uh that we're going to do something a little unusual which is to have a two-minute break uh in between.

So, in the first part of the call, um we're going to be talking about uh well, there be a couple of of uh ZKVMs that are now open sourced. There's some newly tracked ZKVMs that didn't have an opportunity to introduce themselves in the previous call that can do so. Today, we're going to have a bunch of updates on things that we've been working on within the EF. So five uh short presentations and then in some sense um the the main part of today's uh uh uh call is the the talks on real-time proving. Some of these teams have already achieved real-time proving and some of these teams are very very close and will give us uh progress updates on

on on where they're at. We're going to have this this two-minut break uh with an interesting um uh surprise uh and then we're going to have various speakers talk about different types of proving proving with GPUs, proving with AS6 as well as distributed uh proving. Now, one thing I wanted to plug real quick is the House of ZK EFroof Summit event uh which is happening in Berlin very soon, June 10th. Um this is a totally organic event. The e- proof team is actually not uh directly involved. Uh it was uh proactively uh led and organized by the house of ZK uh

team. Uh but I think it's going to be a fantastic event. Um and uh I think there's limited seats and we're close to limit already. So do make sure to um to apply if you'd like to to join in Berlin. Now, um, one of the things that I'd like to to to do here is, uh, just highlight probably my favorite piece of hardware now that I've discovered it, which is the Raspberry Pi Pico2W. Uh, and the reason why I highlight it is because I believe that this device can actually uh, run a fully validating Ethereum node. Um, both the consensus layer node and the execution layer node. Um, and the of course the

the the way that we would achieve that is uh through uh through ZK and you could have validators and wallets and all sorts of entities uh basically just run on this type of hardware. It costs $7. Uh it has Wi-Fi connectivity so you just plug it to the wall. You don't need a host computer. And amazingly I discovered this morning that the CPU is actually a dual core risk 5. So if we do end up having risk five ZK VMs, there's a little bit of an inception here where we're using a Ris 5 CPU to verify execution of of RIS 5, which is kind of cool. Um, and it's ultra low power. It's less than one watt. Uh, which is less than one year, $1 per year of of

electricity consumption. So if you are uh kind of this decentralization maxi cyber punk, um, I think uh this is this is the new benchmark. No, no, normal Raspberry Pi. We're now aiming for the Raspberry Pi Pico. Now, um this is the updated uh tracker of of ZKVMs. And since last time, I wanted to highlight uh a few things. One of them is that we now have uh more open-source uh ZKVMs. Uh so we have uh Pitra, which is open source. Uh we have X um that was open source today. uh and we have uh Bjum 2.0 uh which will be open sourced

uh imminently. Uh I guess I wanted to so Petra has already been announced and I wanted to open up the floor to to John to say a few words about the open sourcing that uh happened uh today. John. Hi everyone. Um, so this is the uh X uh ZKVM. Um, we just open sourced it this morning um after a lot of fun back and forth with uh Justin and folks. Um, it is uh this is like a pre-alpha state, so a lot of things are still broken, but uh the the skeleton of the repository is there. And um uh we uh released this to

zkVM: Ix

to illustrate sort of this idea of using uh lean 4 to um act as the source language for zero knowledge proofs. Um and specifically this idea that we're calling zero knowledge proof carrying code of compressing the um formal proofs into a zero knowledge proof. And we have a whole bunch of examples of what this can be used for. And uh the example that I want to just take a few seconds to to talk about is this idea of uh embedding format's last theorem in for the margin of uh format's margin note. And so you can actually fit a GRS 16 proof in the same amount of space that that margin note is. And so this mechanism uh with the lean formalization can take the

entire lean formalization of modas theorem and turn it into um a zero knowledge proof. Can't do it yet. Formalization is not done. We're not that's being done in Imperial College London. Um but the goal of this project is eventually to do this and uh fit the whole proof into into the margin. Um and this is really useful because uh ultimately when you know everyone on a lot of people on this call are doing formula verification things. What we want to do is be able to offer you guys the possibility of taking your formalization work and compressing it into a proof so you can ship it to your users really really easily.

Okay, amazing. Thank you so much uh John and uh yeah, congrats on open sourcing and very exciting because X is a very very unique uh ZK uh VM. Now, unfortunately, um uh Bjum 2.0 even though they were hoping to open source by today, they had a a little bit of a of of a delay. So I don't want to leak too much alpha but I'm hoping that within the next few days by the end of of this month uh there will be uh open sourcing uh happen. Now the other thing that I wanted to to highlight is that um there are more ZKVMs that are that are being tracked. Um one of which is still redacted. Uh I guess one clue that I'll

drop is that it is a Fortune 500 uh that is uh looking to build a REST 5 ZK uh VM which is uh quite exciting. Um and so uh what I'd like to do is basically go through uh these new ZKVMs and and give them an opportunity to introduce themselves uh in a couple minutes. Uh starting with Lietron and I believe u Mu will be presenting. Hi everyone. Let me just quickly share uh my screen. Um thanks thanks Justin. Great intro. Uh really incredible to be part of uh this group of people who are

zkVM: Ligero

pushing the boundaries of zero knowledge having been like studying zero knowledge for about two decades. Um, I'm putting up this thing that, you know, Justin already talked about his fascination for the Raspberry Pi Pico. And this is a question we want to entertain at uh at Lihiro. So, let's um Oh, that's the that's okay. Oh, sorry. Um, what's Liatron zero knowledge? It's the Lihero based zero knowledge proof that we are developing at Lihero, Inc. uh it's memory efficient and there's a technical term what I mean by memory efficient and it's a ZKVM based on the web assembly uh intermediate representation today this zero knowledge proof on a chrome browser

on Apple M4 Max uh we can prove about 27,000 Poseidon hashes and thousand eddsa on the BN254 prime not a small prime but the 254-bit prime um per second and I want to say that you give a faster GPU. I think on the 5090 this is like more than maybe three and a half to uh four uh four times faster uh on a on on a single 5090. So really here is a question that I think is pos possible one that we might be able to demonstrate sooner is that you know if you consider uh the Ethereum blocks based on the Poseidon 2 hash on a 254-bit prime as well as the EDSA signature we could get

realtime proving from a browser on an Apple M4 Max but the question here we are not talking about modifying the Ethereum stack so really we're asking can we do this on a browser today So um if we compile rats to vasom which is what most people are doing in the ZKVM space to to prove Ethereum uh uh blocks uh today on a browser with the liatron system our projection is this is going to take 25 minutes. Uh I think impressive as it sounds already that we can prove a block on a browser I mean this is not real time proving. So the question I want to here I want to not question but I want to tell you the direction we are taking where we think the current state can be proved. let's say from a you know a commodity laptop.

Google wallet recently incorporated a zero knowledge for identity verification. That's not very important. It's nice but not very important. Uh I want to talk more about the text stack they used where they had used Lihero as part of it and they used a combination of primes. If we do the same where we could do the catchup side of it on the GF and the ECDSA on the prime friendly for ECDSA our projections indicate we should be able to do it. So follow us on uh you know on X uh you will find out uh by uh by Q3. Thanks.

Thank you Mu. Um any questions feel free to unmute or raise your hand or ask it in the chat and I we'll be relaying the the questions. Open source question. Yeah, I saw the open source question. We we're going to open source it. We said July, but we hope to do it like in the first two weeks of June. Okay, amazing. I will be updating my tracker for June. Thank you again, uh Mu. Next up, uh we have uh Maiden.

zkVM: Miden VM

Hello everyone. Uh can you guys hear me? Yes. Awesome. Uh well um thank you Justin. Hello everyone. Um just want to say a few words about Miden. Um Maiden has been kind of open source VM for a while. Uh I've been working on it for uh a few years now. Um I think uh like one to summarize Maiden it's a customiz. not a ZK uh it's not a risk 5 VM and we prioritize a few things like uh specifically safety recursion friendliness and client side proving uh and I'll talk about safety features in a second but recursion friendliness for example where uh our goal and what we're doing with Miden is that we use the same

uh VM both to execute programs and to recursively verify itself so we don't have you know two different VMs one for recursion one for uh the baseline ISA uh and then the client side proving we uh try to be memory conscious and with small proofs and things like that. Uh so um you know our proofs and you'll see later is um you know like 8 80 kilobytes to 100 kilobytes in size. Um and uh overall we can you know for programs that we care about uh in a context of like proving relatively small programs we can do it at actually um you know just with few gigabytes of RAM. Um, Maiden is a starkbased uh VM. Uh, we are migrating to plunky 3 uh over the

summer. Right now we're using Winterfell prover that uh I wrote a while back but we will be moving to plunky 3. Um I think there are several unique features to miden which uh you know besides the custom ISA make it really different. So for example it is not a vanoman machine. Uh instead we have the mercalized optric syntax tree based program representation. Uh it has a couple of interesting properties. For example, you um you know, you don't have call by memory address. You you do call by hash, which makes dynamic linking much more safer. Like you you always know what you're going to be executing when you you know, make a call to an external function. Um you can uh hide parts of the program and like basically u reveal only parts of the program program

publicly and um you know, whoever needs to verify the program doesn't actually need to know what all the branches that are taken in the program. Um in the VM we also have like multiple isolated contexts. So like you have uh memory isolation enforced by the VM itself. Uh uh we also have this notion of configurable current kernels uh which u uh we can um you know basically use to uh enable this interesting approach to pre-ompiles. I already mentioned the proof size is fairly small. Another important thing for client side proving is that there is no startup time. you can basically start executing useful program with within like a first cycle of the VM. So, uh our sometimes you can have a program that executes just for

5,000 cycles and it's like very very fast. Um the way we are working with the compiler is that we have like a uh rust compiling to web assembly components and that gets trans transpiled to maiden assembly. Web assembly components are here interesting because um it allows us to um kind of enforce this uh no no shared semantics between different modules like this memory isolation that I mentioned uh before wasn't components enforce it by default u and yeah there are few things we're working right now on pre-ompiles being one one of the things we want to do with pre-ompiles is that um the adding a new pre-ompile would not affect the circuit of the VM so you can use the same verifier regardless of the number of pre-ompiles

and Then our target is to have the uh EVM proven on Maiden once we have pre-ompiles like this is like one of the major blockers but but we'll uh be able to do it uh hopefully in Q4 of this year. Amazing. Looking forward to EVM proving we're overtime but I'll just relay the last qu the question real real quick from Jacomao when uh multilinear proof system. Um we're we're looking into that as well. Maybe with some of the the new Jag PCS stuff it would happen sooner than rather than later. Okay, fantastic. Uh, thanks thanks thank you again uh Bobin. Uh, next up we have an extremely unique uh VM and project uh called the NOCV VM. Uh, and I'd like to

zkVM: Nock VM

invite Logan Allen to the stage. Hey everybody. Uh, been a crazy last couple of days because we just launched our uh, ZK proofof work system uh, Wednesday. Um, so running on a little bit uh low sleep right now, but we've got Nox CKVM. Uh, it's what we view as the minimal ZKVM. We support 12 base instructions alongside arbitrary extensions which we call jets supporting custom math and cryptography. At the beginning, we we've only written uh tip five hash support and shore signature support using cheetah curve whichos created. We have formal results showing

121 bit security level using the Goldilocks prime field alongside showing that we have a 10 10x more efficient uh wrap than existing risk five systems in terms of trace and gate counts. So particularly our trace is uh our we have linear rows to opto codes in memory and our trace is tiny with 395 field elements with only 175 degree for transition constraints. uh and that's notably for uh a touring complete ZKVM here. So we have a preprint with formal results being released in two weeks and the NOX ZKVM notably an earlier version of it is already open source and incorporated into uh the ZK proof of

work chain we just released two days ago as its proofof work puzzle to start bootstrapping proving capacity um broadly and basically instantiate a performance competition around uh hardware. So notably um we've spent almost all of our time in CK research strictly on the wrap so that we can basically move it between different PCS schemes. And so um obviously there's a lot we can do to move it out of what it's currently in which is using Goldilocks and starts.

uh a lot of investigations to do from here, but we're really excited to have uh gotten the actual uh proof of work competition out to the public and uh going to have this pre-print out with these formal results uh very shortly. Amazing. Just on time, Logan. Um so you have this extremely minimal ZKVM. Um, and I guess one of the things that makes you unique is the the proofof work aspect is the idea to try and bring in tens of million, maybe hundreds of millions of dollars of incentives to go build uh, Snark AS6. Yeah, that's exactly right. So the concept here was we saw this large mismatch between the existing um VCs providing lots of money

to approver hardware acceleration companies without necessarily um already having sustainable business models for for those types of companies. And so we saw a demand mismatch where there's until uh proving gets to have a good enough dev experience and is easy to integrate into into existing applications, it'll be rather difficult for for those types of companies focusing on ZK hardware acceleration to actually have sustainable businesses. And so what we wanted to do is to try to um fix that incentive by providing a block subsidy for Zj performance uh research pra made practical in the real world so that we could try to uh commodify Z proving.

Okay, perfect. Thanks again um Logan. Next up, uh we have uh SP on the Hyper Cube, which seems to be a totally from scratch rewrite um an independent project from from SP1. And I'd like to uh invite Ron Ruff Blum uh to the stage. Everyone, let me just share this. Can you see it and hear me? Yes. Okay, great. Hi everyone. I'm Ron Rothell in head of cryptography at succinct and it's really a pleasure to uh introduce SP1 hyper cube our new version of SP1 which we're really excited about and we released this week as part of the real-time proving uh announcement uh which John will elaborate on later. So let me focus on

zkVM: SP1 Hypercube

the proof system. So SP1 hyper cube is a multilinear based proof system. We found multi-linear polinomials um just much more um flexible and fun to be honest to work with. uh a lot of things that are difficult with univariants turn out to be uh much nicer with multivariants. As part of uh one of our main technical contributions is this idea of a jagged PCS. So we released a research paper about it. In a nutshell the idea or the observation is that in the context of a ZKVM we want to commit to the computation trace which has this sort of a jagged uh structure. So we have a bunch of tables that contain columns of different heights. we want to commit to them. In a traditional starkbased proof system, you commit separately to each

column and that comes with significant overhead. The idea in jagged is to pack all of these columns together and commit to them as one uh multi-linear but still be able to emulate the kind of jagged structure. Using jagged we were able to solve two of the key problems that we had encountered previously in ZKVM design. One is the fact that at least in a starkbased proof system the column count uh really introduces a major overhead. So as you want introduce more columns you pay quite a lot for them. Jagged gets rid of that. A second one which a second problem which is a really key one is what's known um as a combinatoral explosion or the shape problem which is the fact that again in a traditional system you have a lot of

uh branching based on the actual column heights and this branching which might be different in different shards of your proof system causes a kind of major difficulty I would say uh in recursion and jagged also solves that it's also quite a lightweight protocol so I hope others will use it as well in terms of performance performance with SP1 hyper cube as compared to the previous state-of-the-art which was SP1 turbo where you're seeing a 5x improvement over tasks like Fibonacci and loop in which the underlying proof system can really shine and uh you know very nice 2x improvement for pre-ompile heavy workloads um and this was kind of a big part of the real-time proving um achievement I would say and I think John will elaborate on that later.

Okay, perfect. also just on time. Any questions uh for Ron? I guess one from me is that um I think in in your research, Ron, you've been like pretty like for forwardlooking I guess naturally as as as a researcher. Like how much juice do you see is left in improving the proof systems? We you've introduced a kind of two to 5x optimization with this new proof system. Is there much more juice to squeeze? I I I feel that there is. There's uh plenty on different axes. Um Mu mentioned memory which I've personally been really interested in uh worked on for for a long time. So collaborated at some point I think there's plenty there in terms of time. I think there's quite a lot more

to be done both on the research and engineering. Got it. Ron, thank you so much uh for the for the presentation. So we will be going back to my slides real quick. Okay. So the other thing that I wanted to highlight is the sheer number of integrations that we're expecting in Q2. That is by the end of next month. We have 10 integrations that we're expecting from from ZKVMs. And so what is today a fairly bare bones website with e proofs with only four

integrations should uh dramatically uh grow. So uh if you uh would like to integrate uh with EF proofs, make sure to contact Will uh Kokoran who uh will be helping with with coordination. And in addition to the ZKVM teams integrating with Eve proofs, uh we have two new pure prover integrations that are expected. Uh one from SCIC and one from Ferma. uh both of which uh you'll be hearing from uh later today in the presentation. Actually, you'll also be hearing from Snarkify and uh ZK cloud. So, these are entities that haven't designed their own ZKVM. They're reusing existing ZKVMs and then they're

providing prover services uh for those uh ZKVMs. So, a total of 12 integrations hopefully uh by the end of of June. Um, okay. Well, that's the end of uh my slides. Uh, what I'll do now is open it up to the uh efers uh to give various updates starting with Alex Hicks on the real time proving grants.

EF Update: Real-time proving grants

Yeah, thank you Justin. I'll just share my screen quickly. Oh, there we go. [Music] Okay, you should see it now. Y um yes, so fairly straightforward I think as was mentioned last time essentially uh we want to make sure that we're supporting the teams which are pushing performance and getting us towards real time proving. Obviously with uh SP1 Hyper Cube and and Vizer's recent announcements, it's clear that we're essentially very close to getting there. And so just wanted to formally announce and guess following up on the last call. Um we are going to offer

three $100,000 prizes. Uh the eligibility for these prizes is to prove 99% of blocks in under 12 seconds. Uh the payouts are structured in two payouts. So you get 50K after the first months, 50K after another five months. And the criteria is also to have an open source proer. It's first come first serve. Uh, I suppose it for Succinct and RZero, it's just a matter of time until uh until that's done. And uh obviously we're very much on the lookout for a third person or maybe a mysterious competitor that will come up and steal a prize.

Okay. Uh Jordi asks, "Any minimum security level?" Good question. Um I think right now everyone seems to be on the same page with respect to 100 bits. I think that seems like a good baseline to work on. And uh Chris Pruce has 128 bits, you know, listed as a green piece of slice, but I think for now 100 bits is a good baseline. Okay. Uh any other questions?

Just feel free to unmute. um any requirements for the amount of GPUs e i.e hundreds of 4090s may not be feasible. Um I think obviously the prices are kind of indicative of maybe where we'd like to see costs go, right? Uh if someone wants to spend a million dollars on GPUs to get, you know, 100k, I think that's up to them. um kind of it should be fine I think.

Yeah. And we'll see in the upcoming presentations that uh the number of GPUs may actually be very very reasonable to to get to to real time uh proving. Thank you Alex. Next up uh we have Ignasio who will be talking about proof of killers. Um yeah let me share the screen for a second. Can you see my screen? Yes. Yeah. So, I just wanted to uh do a quick mentioning on this CGVM benchmark suite that we have been working in the last weeks. Um this is joint work with Kev Powell and Mario also from DF and I also want to mention uh

EF Update: Prover Killers

previous work from Connor from Prooflabs and IO from Consensus that have also done previous work on CQVM benchmarks. So the idea here is to have some kind of standardized uh benchmarks for op codes and pre-ompiles that is not only covering average cases for proving blocks but also um worst case scenarios or challenges for cigms. So the idea is to have a corpus of uh this kind of benchmarks. So we can run in multiple CQVMs and multiple ER clients compiled to the CQVM targets and also as core developers we want to quickly iterate on which protocol changes we have to do to really

uh align more to CVM proving. So the general strategy for this is uh leveraging the existing execution spec test repo that all the clients already support for running tests. So we can um create all these um benchmarks that you can run on uh multiple combinations of CGVMs and EL clients. So the idea is that if you are a new CGVM uh you can integrate to this CGVM bench repo and you can run all these uh standardized tests and you can see how your CGVM behaves on these challenging scenarios or how it compares to others.

So here are some links to this um to the CDVM uh latest release which already has some really good coverage on pre-ompiles and up codes and kind of uh also attacks related to some protocol um workings and also two links to rean repos that I think Kev will be talking later. So yeah that's it. Okay, thank you, Ignasio. Uh, any questions for Ignasio? I think the goal here is um you know to try and standardize as much as

possible the the uh the benchmarking of the of the provers. Um, you know, as we'll see very very soon, um, we have this new page on e proofs dedicated to killers, but it's completely empty. And part of the reason is that it's been surprisingly hard to benchmark these things. We've had all sorts of crashes and, you know, file format issues and and and and you know, also uh a bit of a barrier to entry to to crafting these killers. But uh, go ahead. I have a question on the prover killers. Uh do we need uh to generate a proof that's verifiable onchain? Uh no. Uh because we are mainly interested in proofs that will be

verified by a test. So at least that's kind of the main idea. Okay, understood. Uh thank you, Ignasio. Next up, uh we have a very interesting uh development called the killer's killer. Uh so there's a a new research idea from Julian and Kev uh that possibly uh is going to remove the the worries and issues that we have around killers. So uh Julian, the floor is yours.

EF Update: (Prover) Killers Killer

Yeah, thanks for having me. Uh so I'm here to give an update on this new research uh by K and myself and Justin came up the name killers killers uh as it solves problems related to prover killers. Um so as we know prover killers cause issues because uh the build the the builder n makes a block and gains the profits of it but the prover n plus1 incurs the costs of actually making this proof. So the system is not incentive compatible. Um, and so Kevin and I proposed a mechanism that does achieve incentive compatibility. And what it does is it assigns the responsibility of proving block n to the builder plot n but enables the builder plot n to force include the proof into the block of slots n plus1. And we do so by

leveraging a for choice gadget that's been best described by Franchesco in viewmer merge. And it's a fortress gadget that's used as well in fossil and in meb burn uh in all of these designs basically. Uh and what it does is testers locally see observe a proof and they observe whether that proof was on time or not. Uh and they um force the builder to uh include the proof if it was on time and if the builder couldn't have seen it on time then it doesn't have to include it. Uh and so uh what we allow here is we gain the benefits of delayed execution in that there's more proving time uh but uh we keep the benefits of um the incentive

compatibility of having the proof attached to one specific block. Uh so a key part of this proposal is that we need to set a proof observation deadline and that means that real-time proving might have to be slightly faster. So for example, it could be within 10 seconds. Uh but it does gain us um that we get this incentive compatibility and so prover kid blocks aren't as problematic because the costs of proving are then associated with the person that gains the benefits from the block. Uh so we gain incentive compatibility. So if this was hard to follow without a laid out timeline or if you're interested in more details, I'll post a link to the E research uh post in the chat and you can text me as well.

But just to reiterate, we solve incentive compatibility of proverkillers by assigning responsibility of um of proven block to the builder block. Thank you so much Julian. Uh the link to the E research post is in the chat. Uh and yeah, basically the idea is that if you're the proposer at slot N and you propose a proof of killer, well, you're dossing yourself. You're griefing yourself because now you're also responsible for generating the proof. And if you can't generate the proof, you you miss the slot and you get penalized. Um so yeah, it's a very very nice idea.

And the way that I think about it is that we don't need the ZKVMs to prove every single block including worst case blocks in 12 seconds. We just need them to prove economically relevant blocks most of the time. And 99 the percent 99% uh seems uh seems sufficient to me. uh even though a little bit more economic analysis is is required here. Um I'm not seeing any questions in the chat. Uh so I'll move on to Kev who will be talking about ZK boost and various other initiative he's been working on.

EF Update: zkBoost

Yeah, thank you. Uh let me share my screen. Um Okay. Can you see my screen? Yep. Cool. Yeah. So, the goal here, uh, yeah, as we all know, is to integrate the ZKVMs into L1. Uh, possibly starting off with offchain proofs. Uh, and yeah, if you're pretty astute, you'll see that my slides essentially uh look exactly like Ignashios and that's cuz he showed me it yesterday and uh I just basically copied it. Now the three initiatives that sorry let me move this out of the way. Uh the

three initiatives that I want to talk about today is guest program correctness zk rest and zk boost. Uh the guest program correctness is basically us uh going to the existing EL clients and uh either helping to inte ourselves integrating a stateless function. So this is the function that actually gets compiled to risk 5. Uh I've put a QR code here for the ref one that we're currently working on and we we've reached out to Erex to see if we can also add them to the list.

uh zk rest essentially once you have uh zk proofs you can then have a more minimal client that essentially receives blocks receives the proof uh verifies the proof and they don't need to have all the state state transition the logic for the state transition uh function in their codebase and this is what zks is uh we want to start integrating we want to start testing uh end to end integration next week uh I can if you DM me I can give you a link for the public Telegram uh bridge that we have for L1ZKVM. It's bridged to our public discord channel and this is in collaboration with ref in particular Roman. I'll just move this out the

way. Uh and the last one is ZK boost. Uh essentially we could have the verification keys be embedded in the ZK stateless client but a better abstraction layer is to have uh this other software that stores the verification keys, compiles the programs and allows you to verify the proofs. And this is what we're calling ZK boost. Cool. Yeah. Thank you. Fantastic. Yeah. So, Kev is working on basically middleware to integrate everything a little bit like me boost in the context of of ZK. So, it doesn't matter which execution layer uh client you're using, which ZKVM you're using

this kind of this common middleware to connect connect everything. Uh again, I'm not seeing any questions in the chat. So, we can uh power on. Uh next up I will be uh sharing my screen to talk a little bit about uh EF proofs v2 uh which has been uh quietly launched uh yesterday. So there's all sorts of cool features on on v2. We have uh these new charts uh you can change the various time frames. Hopefully at some point we'll have the one-year time frame and you'll be able to see the 10x exponential decrease over a period of of one year. Um we have uh ZKVMs uh page.

Ethproofs V2

So right now we only have two ZKVMs. It tells you the name of the ZKVM and the team and all sorts of other information. Um we have a clusters page. Um these are the proving clusters. So here we have four. uh gives you information as to whether it's open source, whether the binary is available uh or costs and latency of course. We have this new page, the killers page uh which is not yet populated but should be very soon. Um and we generally have just more information uh on the website. So for example here if you uh open up you can see uh you know what a bit more

information about the machine that's being used. So how much RAM is there, how many CPU cores are there, how much CPU RAM is there. Uh and over time we basically want to incrementally add more and more information. Oh, and another thing that is super cool that I wanted to highlight is the pizzas. So, um, sorry, there's too much going on on my screen. Um, so if you open up, uh, the pizza here, you will, this is kind of heavily inspired by L2 beat, you will see eight different, uh, pizza slices. Uh, and, uh, for each uh, you will have three different colors, uh, green, uh, yellow

or or red. And yeah, there's also a dedicated page for the various uh ZKVM. So it tells you some information at the top, more information about the P size and if you scroll here, it will tell you about the various uh clusters that are using this specific ZKVM. So in this case here, SP1 is used by three out of the four uh proving clusters. And you can you can have some some stats uh here for for each and you can drill down uh uh here as well. So overall uh a massive upgrade uh to e proofs. Congratulation to the to to the to the team who who built it and looking forward to

integrate the the dozen or so uh provers in the coming uh in the coming weeks. Okay. Now on to the main event of this call. We're entering the real time uh proving uh section and I'd like to invite uh John Gillis from Succinct to talk about their recent announcement. Um hey everyone. Yeah, thanks for inviting me uh Justin and everyone from the EF. Um yeah, I think the ETH proofs initiative has been uh super productive and it's really nice to be measuring everyone against each other because I think it motivates us all to um ship ship faster and ship real-time proving

Real-time Proving: Succinct

faster. Um yeah, so props to them. Um anyway, so I think on Tuesday this week we announced like our latest numbers on real-time proving. I think this chart basically like summarizes our current state of numbers. Basically from April 19th to May 3rd um we ran like a scientific experiment where we basically tried to prove um using ref um Ethereum blocks every 10th Ethereum block and the summary of that experiment was that um we can prove 94% of the blocks under you wait I think hey sorry about that. Yeah please make sure to mute yourself. Go ahead John. Um yeah, so we can prove 94% of the

Ethereum blocks in under 12 seconds and we can prove I think almost 99% of the blocks under 13 seconds. Um so yeah, that's like the kind of current state of our performance. We think we can improve it a lot. Like right now we ran it on 2490 GPUs, but we think we can probably get the exact same numbers with like around 150. And I think we have a bunch of improvements in the pipeline that will improve performance across the board. So yeah, feeling really good about getting to 99% under 12 seconds really soon. And even maybe like a more ambitious goal would be like 99% of proofs in under like 6 seconds or something like that. And then yeah, we actually have also this like visualization where we're proving these

blocks like in a real-time fashion in a demo. Like this is like a block probably from like 20 seconds ago. And you can see that like our cluster is breaking down the proof generation into a bunch of steps. um doing as much as it can parallel and you can kind of get a better idea of the serial bottlenecks here u by like looking at the span of the bars and stuff and you can see that we're actually quite bal neck right now by the executor but yeah I I'll stop here for my two minutes John this page is absolutely amazing I love it uh and I heard that it was designed by you is that correct yeah I designed it but some another engineer implemented it so shout out to him nice and I also heard that this was VIP coded. Yeah, I think there was a lot of

clawed 3.7. Nice. Uh, so one of the questions is how many GPUs are you using and what type of GPU are you using? Um, our cluster right now is set up with 24090s, but mo for most blocks we actually don't use all of them. Um, I think for most blocks we can scrape by by with something closer to 100 GPUs. Uh but basically the mental model is like for a bigger block there just like more cycles to prove in parallel at like peak. So you just need more GPUs. I expect that if we you know 10x the L1 gas or 100x you will need more GPUs as well.

How much power do you use on average in kilowatts? I am not sure. I do think these 4090s have like some standard power draw rate. So you could probably calculate it out during the test period. What was the worst block proving time? I think the worst um in that scientific experiment was something around like 50 seconds and um there was just some block where like it was using a lot of like BN pre-ompiles I think and like our prover wasn't really like optimized for like spamming it at that rate. So I think that's something we can easily fix. Um it was like a parameter configuration issue but yeah there are some blocks that are really bad.

Okay, we have uh questions coming in. What is the peak VRAM utilization across all GPUs for a typical block? Um the 4090s have 24 GB of RAM. Um so we tuned our prover for that but um on the 5090s and other cards they have like 36 to 48 GB of RAM and in those settings the performance is like a bit better. Um but we just use 4090s. Does multiplying the gas estimate by 10x also mean 10xing the proving time? Uh yeah, no it doesn't because basically like one of the things we did was we forked ref to introduce this functionality of subblocks. Um which is basically the idea that like you can

split an execution of a block into separate chunks and then prove from there. So if we input the gas if if we multiply the gas like 10x basically we just like split into more subblocks. Um and we just need more GPUs to like keep up with the rate of work that's being like queued up into the cluster. Um but yeah it doesn't mean 10x proving time. One last question. Will having a single transaction with 36 million gas in the block slow down the proving? Will more broken down transactions help with proving?

Yeah, I think having a single transaction with 36 million gas with our current approach would definitely slow down proving um because there's kind of this like fixed notion of having some state and like applying the transaction on top of it. Now there could be ways to go around this um by again like going to the ref layer even more um but I think there's like an EIP that's like trying to limit the max gas limit. Uh if that get gets merged that will help a lot with real time proving. Yeah. So that's EIP 7825 which I believe there's likely rough consensus on. Uh now the number the question is which number should we use as the per transaction uh gas limit. Okay. Uh thanks again John and uh

congratulations on the on the massive breakthrough. Uh next up we have Jeremy from Ris Zero. Um hello. Let me uh just uh share my screen here. Uh see can you guys see that? Yep. Great. Um, yeah. So, uh, risk zero has also been working on real-time proving. We have actually achieved real-time proving internally in cloud machines. Um, however, you know, we're, you know, less than, uh, you know, I think like only 60% of the blocks or so.

Real-time Proving: RISC Zero

Uh, we're at on the cloud proving largely that is due to the limits of the fastest executor we can get in a cloud. Uh we however are purchasing a cluster because uh effectively our analysis shows we need a super fast executor uh that's like overclocked along with very nearby uh GPUs. But we are currently projecting about 120k for the cluster buildout cost uh to be able to hit uh you know a significant like you know you know 90 plus% of the blocks. Um and we'll know the exact number once we sort of have real measurements on that but we're very bullish. Um, now by the way, I would like to point out that 100% of what we're using to do all of this

real-time proving is open source. Uh, both the GPU acceleration uh code as well as the orchestration code is fully open source. Um, just some real quick numbers. Uh, our executors uh over 120 meghertz and we think there's a lot of room to improve that by the way uh through other techniques. Uh but we're happy with that number right now because it gives us where we need for real time. Um we are our proving speed per uh 5090 is about two greater than 2 MHz and our recursion time critically is less than 200 milliseconds. Uh we also anticipate significant near-term performance improvements on these numbers. They won't probably be 2x's more like you know uh 30% 40% here and there. Uh but

then we are working on a new version of the ZKVM that's uh fairly radically different. Um that's going to bring a huge performance in the proving speed because real-time proving is largely uh limited by recursion and execution in some sense because you can go as wide as you want on proving times. It probably won't bring down the the latency very much, but it should bring cost down even further. So amazing. Wow. Congratulations on reaching real time proving internally on 60 billions of blocks. I did not uh know that. Yeah, and that's and that's that's that's a very large like that's like 200 GPUs or something like that. So it's uh it's also quite quite extensive. Um but yeah, so we're excited about that. Um

and we haven't we haven't done a huge like test set yet. Uh so one of our next goals is to do a much wider set of blocks like you know tens of thousands so we can get real like you know percentages. But but yeah, and how many GPUs would be in that 120k uh cost? Uh so currently we're looking at 24 uh GPUs if we go with the 5090s. We may end up changing we're we're still looking at two different options. Also the um I'm not a hardware guy, the something 6000s. Uh what we found part of the reason we're able to achieve this is we've been able to stack multiple uh proofs within a single GPU machine.

So, we're stacking between three to like six uh simultaneous proofs and we were able to get significantly more GPU utilization that way. Um, part of this was figuring out how to tweak some memory things and such. So, uh so but that's that's the current number. Uh we're also really trying to target under 10 kilowatts. I don't know whether we'll hit that or not. We've noticed that we're not hitting max wattage yet for these devices. So we're still we probably won't be able to know those numbers until we actually get um into the uh to the real real values. Uh one question is does uh v3 accelerate the execution or help with the recursion. Uh it it not particularly it's primarily accelerates the RV32 IM

execution. Um which is why it'll bring down costs. uh we we do have some other potential things we may be doing on the execution side that may massively improve the execution but it's unrelated to the V3 work and then recursion I don't think we'll have much uh much there for a bit either where can I find what will be changed in V3 uh we have not released the V3 source code yet but it's more or less a complete rewrite of the circuit um so the uh mo almost everything at the circuit level. This is basically using the new M3 arithmetization that comes from irreducible and applying that to both our baby bear circuit and to the uh we

will also have support for a binius version of the circuit. Most of the numbers I'm talking about though are on the baby bear version. Um we actually think the binas one might give us even greater performance win. Um but uh I think there's more uh uncertainty there in terms of the the the delta and also the time frame. up. One question from me is around the diversity of the stack. I understand SP1 did a complete rewrite with Hyper Cube. Are you reusing libraries like Plunky 3 or is it also a complete rewrite? So on the uh what's interesting is the V3 is a complete rewrite of the circuit. We're using our exact same um our exact same proof system. Um so that's actually going to be identical to the V2. Uh that said, we the nice thing about the V3 is

architecturally it's less tied to the way our proof system works. So we could move to something like a multilinear thing or we could use existing plon 3 uh or something uh something along those lines. Um and open source of v3 we will open source it when it is released. So we will not be uh using it for any like once it is done it will be open sourced immediately. Uh we're just not open sourcing it during development. Um, so yeah, all of this will also be fully open sourced. All of our we can our goal is to continue to have anything that is production ready be open sourced. We're very strong believers in that as a company.

Amazing. And then final question for me, and this is meant to be a segue for the next speaker. How much time is spent on execution at 120? almost like like what what's interesting is is that execution runs until almost the end. Uh and then you know basically there's only a few seconds in which we do like probably 3 seconds or less for finishing up all the proving and doing all the recursions. Uh so if you're looking at like a if you look at a 12 second block is probably you know 9 seconds of of execution um or something along that that that realm.

Um, so yes, I think execution could be improved dramatically, but we're our current design, we're not expecting that to change in the in the current design that much. Got it. Thank you so much, Jeremy. And congratulations on achieving real-time proving internally and also uh being fully open source, which is uh amazing. Our next speaker is Jordi uh from ZISK uh and um they have been working on many interesting things because it their ZKVM which is designed from day one for low latency and so I'll let them uh I'll let Jordi take it from here. Jordi, you're muted.

Real-time Proving: ZisK

Uh, still muted. Okay. Hello. Yes. Perfect. You can see. Let me see. Can you see my screen? Yes. Okay. Perfect. Well, the the Okay. Okay. So the I mean the main the main improvement as as as you mentioned that we we I mean we released it the last uh weeks or the last two weeks is the 750 MHz uh let's say RI 5 emulator actually it's not an emulator it's just a transpulation from RI 5 code to Intel code. So that's why we can achieve this number. This number is very close. I

mean it's like only four times less uh than the real execution. So that's I think that's an important measurement because this allows I mean the base execution uh I mean the single threat execution to uh speed up uh at the at the at at the limit. Okay. So this is red implemented as I mentioned mean we are developing open source I mean we are uh I mean we are an open source uh project and we develop open source so everything is open source and this is our philosophy uh on that. The other thing that we are working right now that is I mean this is we're adjusting a lot of the I mean we are in the in this place of adjusting the you know all this part that's highly paralyzable I mean adjusting the sizes and the times of the

different pieces so that there is good balance between all of them we are changing a little bit the in the schedule for this balance so that uh all the GPUs can work uh all the time uh working in in something so this is something that we are working hope that in the coming weeks uh uh in the coming weeks uh we have all these ready and also well we are we already mentioned that but this uh 0.15 seconds I think there is here still a little bit of margin I mean maybe 0.1 seconds here for the full aggregation so this is I mean with this uh we hope to reach the the I mean the real time uh proving uh very soon which is the goal from the from the

first from the first day I mean we as I don't like to give numbers because uh I mean my philosophy is just uh we give numbers when we have something that's open source that everybody can verify uh and uh to show but yeah the target that we are is 12 seconds uh on that of course future work how formal verifications subsecond proving we can talk about paralyz instead of having a single processor having like multiprocessors and things like that that can help a lot but yeah we can this is the the the work that we are doing right now amazing thank Thank you, Josie. And I just want to relay the a comment from John Gibbus saying that 750 MHz is mind-blowing for anyone not aware. It's

definitely compared to all of the competition close to an order of magnitude uh greater. So, congrats on that. Um that alone might have a massive positive impact on on the whole industry. One of the questions we have is on which machine did you achieve 750 MHz? just a normal this is in CPU so I mean this computation this we will call the minimal trace this is not it's the part that's not parallely zable and this is just a CPU I mean and uh the important is not the number of cores the the important here is the frequency of the core I mean if we we are can we are being able to run in a let's say an over overclocking machine maybe going at six

gzertz uh maybe instead of being 700 MHz maybe it's 1 ghahz or 1.2 gigahertz. So it's the the the the important I mean we we are translating risk 5 to Intel uh assembly. Okay. So and translation is one risk five is I don't know three four five uh intel instructions. Here in these instructions, we add also add the the instructions to generate these minimal trace which is what you need in order then for running again or doing whatever but already in parallel maybe maybe machines on that but this this piece is uh and this is just um I mean it's just assembly and I mean a transpilation trick I mean it's not relevant to the machine and the relevance of the machine is what's the clock uh uh uh in the Intel.

Uma asks what memory argument does this use? Is 700 MHz just emulation of this fiber or does it include the metadata for the memory argument? No, for the for the memory uh I mean uh so you're referring memory argument for the for the proving is very much uh I mean it's just a normal I mean we are just sorting all the reads and writes and then sorting out uh uh uh uh sorting out uh later later on. Um uh yeah there is a special running uh thing for the memory but uh that's just taking but at the end you you you run it again in different uh in in different machines. For the execution part it's um

that's that's that's a different that's a different thing for the minimal trace. The idea is that we are just storing the reads so that then we can execute a specific code u in parallel mean with different chunks in parallel without needing the memory because we already have all the reads. I mean instead of accessing to the memory we're just accessing to the transcript. So that's the main idea for for for this to run in parallel. Nice. Uh and Amma highlights that uh another exciting thing is that you support 64bit.

uh one question that is this limits a lot this I mean this reduces also the number of clocks which is uh it's also another I mean if you compare with a 32 bits probably I mean it's not a 2x but maybe it's I don't know 20% 30% uh better because of we have less less less clocks in overall uh in the in the overall system great and franched one of the previous questions the machine is a 3.1 GHz server with 32 cores um one of the question Is does Golang support mean that you support the G extension?

I mean we are currently we are supporting just uh basic integers multiplications uh integers and multiplications uh we are not supporting u floating points but I think that there is some emulation way to build that and then there is other extensions that's more about bit uh modifications I mean it's bit instructions and things like that that we are not supporting right now but they should not be hard uh to support we haven't implemented them but all these so going to ag if we emulate I mean if we do this um this five uh I mean we substitute these instructions for uh emulated uh um floating point

which in the in the in the context of blockchain makes not much sense uh we should we should show we should be able to support the risk 5G got it Jordi thank Thank you so much uh for presenting and congratulations on this uh execution uh speed. Thank you. Next up uh we have Mo Dong from Brevis who will talk about uh Pico. Uh thank you Justin. Uh so uh we're uh today here to just give a quick update on where we are uh in terms of achieving uh real-time proving and also our

Real-time Proving: Brevis

Eastroof integration. Um so uh brevis pickle um we started the GPU acceleration uh you know implementation a bit late in the game. We started around March but uh you know we're kind of trying to speed around this uh um to achieve the best performance here. Uh so uh you know we're very very close uh to our first version of the GPU implementation uh release and uh you know on uh one single card of uh 1490 uh will are achieving about six times faster performance than our previous generation uh CPU prover um running on 192 cores and uh you know pic is a modular uh zik VM that we support both

colabar and I'm 331 uh you know field on uh the GPU version as well. So you can still switch between different field if you want and um uh you know uh we have do have multi-erver clustering supported but right now that that is not optimized and something that we are kind of working hard towards and that's part of uh uh our effort towards uh real-time proving and uh you know one things that we uh you know uh also have a product that is uh you know allow a smart contract to access historical onchain data and the wrong computation on top of that what we call that as a ziki data co-processor. We also have that uh Zika co-processor GPU version available and integrated with uh you know the Z VM we have as well uh

this is already powering some of the major DeFi protocols for reward distribution such as like Euro money which is one of the writing starting the stable token ecosystem in Ethereum. Um so we are now quickly integrating with Eastroof. We have all the API integration done uh yesterday and we will go live very soon once we have our GPU uh 1.0 released and uh you know for the pie charts uh sorry for the pizza charts we have audit in progress and security review uh competition is starting soon. So if you are interesting participating that uh we u you know wholeheartedly welcome you to do that.

uh for the progress on uh real-time proving uh you know we uh uh you know we have like kind of a parallel in parallel implementation for optimized clustering uh you know we expect this to be very uh you know ready uh in a few uh in in a few weeks and uh you know uh we very much focus on reducing the cost and understanding procure better with public bench uh public benchmarks um you know uh in addition we're also working with a hardware vendor on specialized hardware design uh code design with with the VM as well.

Thank you. Mo, you mentioned optimizing cost. Um how expensive do you think the cluster of GPUs will be to achieve realtime proving? Yeah, right now so we're uh you know estimating around 150 uh 4090 to 200 uh 4090 very much on par with like uh you know what uh other teams are presenting here but you know we do think there's still a lot of room to improve uh on that uh you know both on uh looking at uh not only just like the the VM part but also kind of uh thinking about potential uh you know race uh implementation changes and also like kind of you know eventually um you know uh some feedbacks that we analyze from kind of looking at uh the

uh the benchmarks in terms of like how you know we think some of the layer one uh you know evolution can also be uh guided through this if the if zk proving layer one blocks is something that we are interested in long term. One of the questions in the chat is um is the work that ZIS did with the executor adaptable to succinct and R0? I was curious if you think it might be adaptable uh to Pico as well. Uh so yeah, this is a this is an interesting question. So uh you know we uh we haven't really kind of looked into that uh yet. Uh but you know Alan, I'm not sure if you have any quick thought

on that. Yes, we do observe that is executor uh plays an important role in the uh efficiency of the whole Ethereum proving or in general the ZKVM performances. So if there's any way that we can integrate a very fast executor that we break um so currently we don't have a a quick answer to that on on top of my head but we could look into that. Perfect. Um, so Jeremy answers, "Yes, in theory the approach should be usable in our proof system as well."

Amazing. Okay, looks like we're out of questions. Thank you so much, uh, Mo. Next up, we have Stefan from ZKM, who will be talking about ZK Mips. Oh yeah. Hi. Okay. So yeah. So um for Zik Mips since uh last last meeting we released uh Zikips 1.0 zero uh in the early May and it's uh already launched on the A proof and we uh we can see that we have a really good

Real-time Proving: ZKM

performance there and uh we currently from our benchmark our ex uh execution speed uh is um greater than um 20 million um per second uh on a single MD uh EPYC uh CPU and the pro uh and the proving speed is bigger than 1 point uh 1.3 uh million uh hertz our single uh RT M RTX uh 4090 GPU cut and uh so yeah and then we also uh the code is uh and our code uh has been open source uh since we yeah since uh we we I think since the

day one so uh we are um under the auditing right now And then the audits would be expected to finish in the six to um uh four to six weeks. And then uh we uh all uh some other works uh is uh the uh cluster proving uh we could uh cam proof network and we finished the pipeline proving uh and yeah last week and so that means we uh cut the um we split the the the trace uh in different segments and then once we split the uh web gener generates a new uh segments we

prove it immediately. Uh yeah it's quite different from our previous uh implementation because uh before uh this uh uh optimization we uh need to split all the uh we need to generate all segments uh then begin to prove and uh we also optimize our stack to snack on on web uh because uh it's yeah it's it's it's not for the east proof right now but it's uh for for some other um you know applications like the our um for the PVM bridge uh on the golden network.

So on our single RTX 1940 uh we it's it takes about two seconds for the wiper uh to being 245 and about two seconds to generate the G 16 proof. Uh yeah so basically that's the update for um uh this month. Yeah. Amazing. One of the questions from the chat is what is the unit for 1.3 million? Is it uh myip cycles? Yes. Mip cycles. Nice. Makes sense. Um and in terms of estimating the cluster size to achieve real-time

proving, is it similar to what others have presented? Uh yes. Yes, we Yeah, it's it's on track, I think. Yeah, nice. Uh any other questions? Okay. If not, uh we let's thank Stefan again and have our last speaker in the real time proving section um which is acting as a segue to our next section on GPU proving uh Oang from Snarkify. The floor is yours. Hello everyone. Um uh I'm glad to

Real-time Proving: Snarkify

introduce you to Snarkify uh team focus on endgame ZK performance. Well, for for people who are not familiar with us, over the past two years, we've built the world's fastest MSMs, won about half of the Z price competitions across GPU, MSM, Wom, GPU, FPJ, and was and we've developed the fastest H2 GPU prover that served the scroll mainet. That being said, let me walk you through how we build towards real time proving. Well, since real-time proving is already here. Um, however, we still need decade to be faster and cheaper with Nest Compute. To achieve that, the most important metric we focus on is the GPU proving throughput. Uh, the number of risk file instructions a single GPU can

prove every second. Uh, because this is the biggest cost factor. U, if you can prove 10 times faster with a single card, your cost will drop by 10 times basically. Uh the second key metric we look at is a risk five emulator throughput. People have discussed a lot uh at this meeting. Um like this is a latency factor because after this emulation the proving job can be scaled across many GPUs and the aggregated recursively. Um I'm glad to claim that Snarkify is ahead of the curve on both metrics. people have reported different numbers today and we we at Snarkify has already achieved faster than the 750 MHz emulating speed emulator speed. So

people are asking can other VMs apply the same kind of technique this team has done. We can confirm that because Snarkite has the same kind of technique and then we will achieve faster emulating speed at a slower uh GPU CPU with lower frequency and um on the proving speed side uh we are on track to improve the single GPU proving throughput by several times compared to the reported numbers today. Um our product will be live on it stock around end of June. So please stay tuned. Um you'll see real numbers at that time. Uh okay. But last um snack has super simple power is simply that we can make any ZVM real time. So we build a full stack in house from scratch from pre primitives

like fields curves and DTFRI to risk five emulator GPU prover to aggregation pipeline that give us the full control of the proving stack. So we're looking forward to partnering with the most advanced ZKVM teams. So if you're building a ZKVM and want to enter the real-time proving territorial um can get you there faster than anyone else. Yeah, that's it. Thank you. Thank you, Oang. And uh yeah, one thing to highlight is that uh Stockify is not building a ZKVM, it's accelerating existing ZKVMs. Um and uh one very exciting piece of alpha that you just leaked is that uh you've achieved more than 750 meghertz

risk 5 emulation. I'm curious, have you broken the gigahertz uh frontier? Um typically we don't like uh release performance numbers before we actually uh launch the product but uh I think the answer is yes here. Yeah. Okay. Wow. I mean maybe projecting ourselves into the future. We'll be living in a world where we can prove statements almost as fast as the underlying x86. uh which would be uh quite a development especially if we imagine that you know right now there's only a factor of four or maybe three delta between the emulation and and raw raw speed and this

can be this gap can be closed with with A6 potentially uh down the line. So quite an amazing development that you know at least there's a a plausible path to just being just as fast as as x86 uh computation. Any questions for uh young I mean I have to ask it. You mentioned that you're faster on the shard proving as well. Can you give a little bit more color on how much faster you are?

Uh several times faster. Um we haven't have the end to the the se into running yet but we have moved all the trace generation to the GPU. So like um as much we we try to make things happen on the GPU as much as possible. So actually we can achieve several times faster than the recorded speed today. Wow, that's absolutely amazing. Um I mean even a factor of two improvement just reduces the number of GPUs required roughly by a factor of two. So that alone is a massive massive development.

So congratulations and uh looking forward to the integration with proofs at the end of June. And uh one thing that I forgot to highlight on the eve proofs v2 is that we now have the multimachine uh pages up. No one's actually submitting multi-achine proofs. Uh but the idea is that uh if you have a cluster uh you're welcome to submit uh proofs for every single Ethereum block. And I'm hopeful that uh we'll have at the very least SP1 res zero and and stockify uh proving every block uh by the end of of June. So, congratulations.

Uh, again, this ends the real-time proving section. As promised, we're going to have a very quick break. Uh, and we have a little bit of a surprise uh that Will, uh, will share. So, do feel free to stretch your legs, get a get a drink or something, and we'll be back in a couple minutes. Thanks, Justin. Yeah, as mentioned earlier, uh, one of the people that has been doing some early studies on proverkillers is Connor from Proof Lab. I unfortunately I don't think he's on the call, but he pulled something together that we wanted to share with you. He loves hunting uh, proof killers as much as anyone, so he made a theme, and I'm going to share this here in a

Prover Killer Anthem

second. Beat that brand new ZKVM. Another one, man. They multiplying like spam commits.

Who's going to stress it till it taps out? Ghost ride your ZK BM straight into the bay through Peterson hash now your stack can't stay trust me bro nah I don't trust it your proofs like my scraper hella busted Phil got curves but the gas too thick mainet choke make your verify sick copy paste repo another lame sequel tweeting benchmarks bro they're deceitful you recursive dog please pause nested so deep made Santa Claus lost back and sweating chain hall drama verifier slower than your grandmama prove for killer slaying every fake VM say you're modular stacks looking shaky man tweet a proof but you can't even

verify proof lab laughs while another ZKVM die every VC got a VM they all the same V code base control C fame change a little field while real clever still can't verify yeah me neither threads on blast mainet slow back melt like Bay Bridge snow doc say trustless that's so fake trusted setup that your uncle baver trying to load sounds Like dial up chain froze up devs in denial. Bro curve so niche can't even scale it. Stress test heavy till your witness bailing. Spin figureates wrong constraints and break them. Boot up stall your mainet faking docks on docks blogs on blogs. Proof lab laughing your VM logs clogged. Prover

killer slaying every fake VM. Say your modular stacks looking shaky man. Tweeted proofs but you can't even verify. Proof lab last while another ZKVM. I drop entropy like E40 slang. You prove or crash. That's bang bang bang. Claim your plunk but you just confused. Circuit sloppy benchmarks bruised. Back in looking janky like scraper paint mainet run. Nah, it faint. Verify gone. Ghost in the shell. Another ZK VM bit. Farewell. Prover crying. CPU frying. Tweeting copium. Whole team's lying. Doc still say alpha release. Proof flap swing. VM deceased.

Hey, Proof Lab. ZKVM graveyard shift. Too many posers. Not enough hits. RIP to another stack. We out here killing dreams. Y Bay Area. Woo. Okay, we have a link in the chat uh to Connor's song.

Congratulations, Connor. Everyone seems to like it in the chat. Plenty of very positive comments. Uh and we're back from our break. So, I hope you got to uh get to drink and uh yeah, stretch your legs. So um now we're going to be focusing on prover technology that is going to bring us to the next level and help us get to real time proving on a smaller and smaller power budget. Um so unfortunately our very first uh pro um speaker Omar from Inyama had a last minute cancellation but I do want to say a few words about Inonama. Um I believe they're like one of the um top um GPU

GPU Proving: Supernational

acceleration firms. They have this library called Icicle. Um and uh they will help any ZKVM out there. I believe uh you know some sort of a consultancy model um get faster. So if you're not aware of uh Inggonyama, do check them out as one of the potential options for accelerating your ZKVMs. Next up, we have Super National, one of the very first teams doing GPU acceleration for Snox. Truly OG. And I'd like to invite uh Kelly Olsson on stage.

Awesome. Thank you, Justin. Uh yeah, so I'll just maybe give a a quick introduction. Uh at Super National, we do high performance cryptography libraries uh as well as silicon. Uh probably most notably, we do the BLS signature library that's used by the Ethereum consensus layer. Um and just wanted to talk briefly about Spark, which is another 100% open source library that we have uh that's free for any team to to use if they'd like. It's fully NVIDIA and AMD compatible uh which is is something we haven't really seen too much out there. Um it's used by some of the leading uh ZKVM. So as John mentioned, it is used by SP1. Uh it's also I believe used by the the riser team and it supports a lot of uh the core primitives uh in porark and stark

acceleration. So we have kernels for MSM NT LDE and we've done done a lot of work on the various uh arithmetic friendly hashes like Poseidon and Poseidon 2 and we also support a variety of fields uh with Spark like Goldilocks and and Baby Bear. Um and if anyone needs you know help with it they're certainly free to contact us. Uh we also do provide acceleration and optimization services. Uh so if you'd like some primitives added to Spark, that's something you know we can certainly accommodate. Um we work on end to end proving acceleration. Um and obviously a big topic here has been around uh the risk 5 executor speed um or the risk 5 emulation. We've done quite a bit of work uh on accelerating witness and trace generation uh there.

And uh for those that are still pursuing client side proving um we do a lot of work on x86, ARM and WOM. Uh so certainly feel free to reach out to us. Uh you can ping me on telegram uh or just get in touch by email. Thank you very much. Thank you Kelly. Um I mean talking from experience uh you give them any task and they'll just make it faster. Uh that's what they do at Super National. Um and yeah thank you so much for making uh Spark open source. Uh I guess one question I have uh for you is um how far do you think spark is uh from you know optimal performance uh is that just to squeeze and same question for risk five

execution do you think you can go well above the the one gigahertz that was uh teased earlier today in the in the call. Uh yeah so in terms of in terms of spark um you know I think there's certainly room for for improvement there. Um, one of the nice things is some of the kernels are actually already faster. They're actually limited by the hardware themselves today. Um, so as we see new, you know, 5090 GPUs come out, Spark just, you know, performs faster on those because many of these algorithms are are memory bandwidth limited. Um, and and you know, I think one of the other key things is that while Spark's a great library, a lot of the magic comes from orchestrating the kernels and you know, sort of stitching them together. Uh so the performance you know I would take the performance you get sort of out of

the box with spark with a a grain of salt because there is a lot of work to do when you actually integrate it. Um in terms of the the witness trace generation risk five emulation yeah I think there's a huge amount of opportunity there you know several times I think most of it could get several times faster. Um I think that there are some alternative approaches that could be taken that you know some of the teams are not doing today um in terms of you know putting inline assembly to sort of directly translate some of these um risk 5 operations to like the the matching assembly on x86. So yeah there's lots of uh lots of opportunity there.

Wow. You've heard it here first. Uh several times faster over the one gigahertz. So at least 2 gigahertz. um the FM foundation could would probably give you a grant uh to do that kind of acceleration or actually many of the VC funded teams on this call might uh also love to to to work with you. So uh very very bullish on these uh potential uh developments. Any further questions? Just checking the chat. Uh yeah, we have John Gibbus and Jeremy uh I believe both CTOs of Reszero and SP1. uh saying that you you guys do excellent work. So uh congrats congrats again. Um next up we have uh Zan with uh

GPU Proving: ZAN

Guing uh who will be presenting. Guing the floor is yours. Uh thanks Justin. Uh hi everyone. I'm Ging from Zen and Anchino lives. I will give a quick overview about what we've done at Zan and and Chin open labs on GPU proving our team would like to lower the barriers for using GPU in ZK to serve and to empower the ZK community. We have accelerated cryptographic operate operators such as MSN entity some check etc. We have a GPU solution for kinds of proof systems such as goose system 16

hard two punk three etc. Accelerating proof system requires optimizing GPU memory memory bandwidth and PC bandwidth. Uh maximizing the resource utilization is key to achieve achieving end acceleration. The right table summarize the performance in performance improvements on the GPU. We achieved up to 121 times speed up uh over CPU. In addition to never ranging the ZK algorithm, we need to address circuit specific computations. Our goal is to of load all

computations to the GPU. Our next focus is on achieving real time proving with as few GPUs as possible. Finally, I'd like to provide a brief introduction to ZAN. As a web 3 brand of ant digital technologies, ZAN provide service for the web 3 community. ZAN is powered by and open letters. We also building Joy and Ein tow. Thank you. Thank you so much and very very impressive numbers. Uh one question for me um when you say small number of GPUs for real-time proving uh do you have a

number in mind? Maybe uh maybe below 100 uh even uh even uh 15. Nice. Potentially 50 GPUs. And would there be 4090s or would you use the high-end 5090s? Uh maybe 4090. Okay, nice. I mean the rough heristic that I have in mind which might be incorrect is that the 5090s are about twice as much. So if you go to 50 4090s that's only 25 uh 5090s which I guess would match the numbers uh that we got earlier today from Jeremy of of risk zero.

Um I guess one question I have is um who do you work with in the space? Uh we've heard from super national that you know their kernels are used at the very least by SP1 and res zero. Can you share some of the the the clients that you work with? Um I think uh I don't think uh it's convenient to mention their name. Okay, got it. Um but is it fair to say that you're a general purpose uh consultancy uh and uh basically you welcome any of the existing ZKVMs of which there's about 25 to come to you for uh for for GPU

acceleration. Yes, definitely. Perfect. Uh let me check uh the chat. Not seeing any further questions. Okay. Well, it looks like we're slowly building a a cottage industry of of GPU accelerators. So, that's that's the end of the GPU acceleration uh uh section. Next up, uh I need to check my schedule. Uh we have ASIC proving. Very very exciting. We have six different teams uh that are going to be talking about their ASIC acceleration work.

Starting with Mingu from Axial Mingu, you might be muted. I can't hear you. Uh, can anyone hear Mingu? No, we still can't hear you. Okay, what about um going to the next speaker just to give you a little

bit of time to to fix any potential technical issues? Uh Leo from Cisc. Hello. Hi. Uh can I see my screen? Yes. Okay. Yeah, sounds good. Uh yeah. So like here I'm uh going to give a update on the like the hardware part about Nexic. Uh yeah. As you know like Cassic is doing like ZK hardwork acceleration from the very beginning and like our design principle here is to say like the ZK computation like from our perspective or like based on our observation is like dominated by by this like two two things like the first is this admin wise

ASIC Proving: Cysic

operations on the arrays and second is a day data layout reordering operation which will make the uh computation like for the next step like uh much easier. Uh yeah so like we have this like hyper cube IR post is um like on our like hack MD. So like based on this like um uh based on this observations we can basically use this like A6 or the the processor arrays like to handle uh this like two kinds of operation and then we use the embedded GPU to handle the edge cases the corner case which we might be like missing or like we might be like add in the future. Uh yeah so for here this like um like I'll talk a little bit

about a little bit more about the element wise operation. So we have like native support for finance field such as golden locks, baby bear like mer or like some others and also native support for the hush function k check to make it to make this like course like much faster and for some like simple course like we have dedicated course to do this like simple arithmetic such as modular arithmetic and then like for the comp complicated ones we like the piece will share the course share the resources to to do the Yeah. So that's for the first component.

The second is a data layout reordering operation. Uh yeah, so like we designed this like symmetric topology for data transmission to make sure like the data transfer is like uh optimal on the hardware and it's near the 100% of the network on chip utilization and it's optimized for this like high demand we patterns like speed up. Uh yeah. So, so here like I'm showing this like four 4x4 P arrays like the Ps like are connected by the DAS by by the like near one near two nodes. Uh so this is for just for de for demos like we the actually like P arrays are way much larger and we have the the RTO's development is like from

the small arrays like towards the full array which is like way much larger and based on our estimate we also have a have like reports on I guess also hacker MD to say we can actually proving uh 1.3 million key check functions per second on just a single chip. Yeah. Like we are looking for like since we are close to our archive phase we're looking for some like collaboration to say if you have some like finite field new finite field or like new high function please let us know so we can put it on the chip to avoid this like very big performance gap between like software and hardware execution and yeah so by the way is like network is also working on like realtime data proving for blocks using the

communities like cluster so like for for the previous test net we have like more than uh 4,000 GPU poofers and more than 180 uh,000 uh mobile verifiers like you can just run the verifier on the cell phone and also on the Raspberry Pi. Yeah, that's all. Thank you. Thank you, Leo. Um Gil asked in the chat, is the RTL open source? The RTL is not open source for now. Um yeah so like when we uh finish the chip tip out like we will open source the RPO like at least that we will open source the P part like for people to see if they can improve on that.

Reza asks uh do you use HBM or what is the memory bandwidth? How much memory do you pack inside chips? Yeah, we we use like a variant of HBM like yeah as you know like the actually like one big bottleneck in the le competition is like the memory uh there are like several like kinds of like HBM like we are still doing some work uh some exploring and some also some research I guess like we can we can probably like talk offline to see like what's the exact uh HBM bandwidth like where are you using do you prototype on FPGAAS Yes. Yeah. We prototype on the FPJs but right now as you know like the FPJ the

frequencies to know and the hardware resources on the FPJ is also like very very short. So we are building like a multiple PCBs where like each PCB have like multiple FPJ chips like to simulate to emulate the results like to emulate our designs RTO design of the ASIC like we will report the numbers probably like in the in the coming months on that. question for me would be um is your ASIC capable of accelerating generic workloads like the existing ZKVMs and if so uh how much performance gain can we get for example on top of you know rest zero or SP1

yes certainly you don't need this like 200 like GPU cards to to to achieve realtime moving if you use like size like in the near future so like our current estimation like one single chip. So be like um one single chip should be like I guess like um five to 10 times faster than this like 1490 GPU cards and we we certainly will pack like multiple chips like in a machine like we have two machines. The first one is called the ZK Air which is a portable machine the size of a MacBook charger. You can just carry around with you and the second is a Z Pro which we pack like multiple chips in that one. Probably you just need a

single ZK pro machine to to achieve like realtime pulling. Yeah. So that's our goal. Yeah. Okay. A single machine can achieve realtime proving. What would be the power usage of that single machine? As you know like we are doing the A6. So the estimation is like it will be around like three to four kilow. Yeah. Okay. Well, that's something I can run at home. Um that's about I guess my oven. Thank you so much. Uh Leo. Yeah. Actually one one last question. Anyone knows how many ketaxs does a 4090 proof per second? I guess that's not a question specifically for you.

Hulk. I can stop uh I guess like 149K is around I guess that also depends on the like proof back end you you are using so the 1.3 million K check we are actually using the variant of GC proof system okay um Mu are you ready to try again so can you hear me now is it better yes yes perfect nice okay let me get the screen. Okay. So yeah, this is Axel uh which is a uh data uh for CK as that uh based on China. So actually uh last year

ASIC Proving: Intchains

we have announced our uh chin one as chip for as for ZK proof. So it was based on TSM 12 nanometer process and this does not use HPM it is like normal LPDDR chip. So it's relatively uh like a chip um processing and here's the numbers. So basically I don't want to emphasize it too much because these are a little bit outdated and but essentially we have the chip like tape out successfully and also we build the accelerator card and finally like we actually also build a few um like machines that really like host those cars in a in array. Um these days we actually u aim for the gen 2 uh ASIC um and it's currently under still under development under design. Uh basically

we are aiming for uh to further improve the MSM and entity unit that is already supported in our first uh generation ASIC. Uh basically uh we are trying to optimize the the mathematics of the MSM calculation especially the elliptic curves and also the architecture design of the uh entity unit and furthermore like as we noticed like there's more kernels that was introduced into the zik uh uh proh protocols these days. So for example, we need to support more flexible like modular arithmetics and also various hash functions that needs to be put in. So uh currently our expectation is that it at least will be like four times faster within the same area cost uh uh compared to our G1 chip.

And at the same time we're also trying to develop a little bit like more customized designs. So basically the first two uh generation ASC are kind of general purpose that we integrate like various kernels in that. uh but we're also trying to uh design some customized um uh designs for uh some TKM protocols like Alo like scroll like etc other things. So basically it will uh introduce the the instructions like support instructions of those protocols and also we build like a micro pipelining that have customized and fine-tuned function unit for those uh specific functions and also um like like specialized optimizations for various hash functions and the micro tree uh uh designs. Yeah, that's all.

Perfect. Uh thank you so much uh Mingu. Um, I remember holding the very first ASIC at ZK Summit, maybe ZK Summit 11, and that was quite a breakthrough. And it's great to hear that you're already working on on V2. Do you have any ETAs for uh for V2 and uh which process would V2 use? So um for the design part we probably want to aim for like at the end of the year we probably want to uh to to freeze the the RTL design and start the back end and probably uh if everything goes well we want to like tape out like next year. Um so for the processing uh for the process of the uh I probably uh it's a little bit difficult for us because

like in China you know it's not very easy to access have access to the the the very advanced uh process. So we are considering like both the 12 nanometer which is probably more uh available or also like the 7 nanometer uh process. Okay, perfect. I'm not seeing any questions in the chat. Mu, thank you so much for uh sharing the latest developments from Axial.

ASIC Proving: Fabric

Next up, uh, we have Michael from Fabric. Hey everyone. Um, let me share my screen. All right. Um well thank you for the opportunity Justin and you know thank all of you for the amazing work you're doing uh in this space. You know we're really impressed that real-time proving has been achieved so early. You know it's it's pretty amazing and uh we look forward to seeing what our hardware can do uh to to advance that even further. Um few things that you guys

probably already know. The chip is coming soon from the fab. Uh this is taped out a few months ago and in the last month uh I have not been on Telegram much. So for those of you not getting responses from me, it is because the chip is now most of the way to finishing. Um you know, we had to sign off a package. We actually opened a Taiwan office. Um we have an AT test socket and board that we just signed off. We rented that. We arranged test engineers uh on the production floor. Uh we signed off what we call our EVB and that's been sent to manufacturing. So basically there's a litany of things

that you have to do uh in advance of production and we are doing those things. Uh I hope to be back online in a couple months pretty much and uh you know within the next year um we are going to I think achieve real-time gigas per second. Um I think it's going to come much faster than what people realize and uh just one VPU server uh is going to be able to prove blocks in real time. Um so yeah that that's our roadmap and Gen two has kicked off if any of you want to talk to me about uh co-designing Gen two uh with the algorithms that you're coming up with. It's much better than I thought

possible. So that's pretty exciting. And a big thank you to the folks uh who made our journey possible as well at Polygon and Riro. Wow. Uh quite an alpha league here. Um so just to make sure I I understood this uh the claim is one gigas per second proven on one single VPU server which is six cards. No no okay it just one VPU server can proves to prove today's blocks in real time. Got it. Yeah. So okay makes sense.

And what is the power usage of this one VPU server? Uh it's actually around the 3 kilowatt range. Okay, nice. So basically each card is roughly the equivalent of a of a GPU today. Yeah, something like that. Nice. Um, so did I understand correctly that you you haven't actually received the the the test chips, but you're doing all of this advanced work with the test board uh in preparation of receiving the actual chip. Yes. So, we have a uh socketed board that basically the chip will go into the very first day that it

comes out of packaging. Um we are actually I think about two weeks away from receiving the first wafers. Um but then after that there's like days of packaging and then putting it on the test board and then there's bring up. So the first day uh your GDDR memory and all that stuff is not going to work. Uh and you have to go through the process of getting it to work. So that's called bring up. Um so there's going to be a process afterwards. But, uh, we're really excited to receive real silicon. Okay. Well, I I can't wait. Um, and I I watched one of your videos from uh a few a couple months ago where you basically

explained a lot of the the testing that you did uh with this like massive cluster of FPGAAS, I believe, to simulate everything. Uh, and I could recommend this video, which was uh very very interesting. Yeah, absolutely. Uh no questions in the chat. So we can move on to uh the next speaker uh Hugo from Inchains. Okay. So uh since Justin, so can you see my screen? Yes.

Okay. Let me uh try to turn off my video. Okay. Uh so de introduced the CF labs VMs solution. Uh uh we have a vision to accelerate a realtime proving for snack ethereum. Actually um we are a joint venture of uh in a chance and uh or labs and uh our partner in the chance uh is a NASDAQ listed company and uh it actually holds ETH as a corporate uh uh uh uh strategy and um uh in last two years and it started

to design the uh JK SQ solutions that we already accumulated much uh many IPS su such as entity, MSM, some checker and so on. Uh we uh in the past uh seven years we already u mass production more than 116 and uh uh we delivered many uh uh miners and uh totally uh we shipped more than 50 uh million uh chips. So we design uh uh miners for some projects including Kaspar area and so on. And so we have very mature supply chain. Our

design target is that actually we already designed a gen one that's for audio project and now we are go uh we are going to gen two uh that's for real time proving and firstly it will for the 10 million gas diameter. Uh but in the longer term we want to design a gen 3 that can support giga gas realtime proving uh we think we could reach uh more than 20 uh uh times energy efficiency and you can see the data from the right side. So uh based on adios project we have more than 20 times uh uh improvements in the energy efficiency and the power should

be less than five uh kilowatt and we it will be a single box design just like we did for audio project and we are working on algorithm study and mo uh we mostly are studying uh v uh v zero sp1 and audio we currently we don't have plan to build our own TV VM and then we will build a LPG prototype and a silicon production and usually it will only take six to eight months for us to reach mass production and uh the most important thing is that we want to build build a kind of open solution and we want to work with it proofs and the whole ecosystem to code design standards as we

have a lot of ZVMs and we hope to we have some joint this uh research and design with our partners especially on the software and hardware code design. That's all. Thank you Hugo. Um yeah and from my perspective it's quite serendipitous that we have a company that's simultaneously an expert in AS6 having delivered you know tens of millions of chips and is also holding large amounts of ETH in in the treasury. Uh it's quite a unique situation and uh I look forward to what you guys uh deliver. We're over time and I'm not seeing any questions from the chat. So uh in the interest of time uh we're going to move on to uh

ASIC Proving: Irreducible

Radi from Ireducible. Yep. Thanks Justin. Um I'm going to share you this slide which is going to go through our proving stack and apologies if this cause minor headache to the people who are looking at the slide and I'll say two things to start my speech with. Well first of all the reducible took slightly different approach in bunch of things on the on the stack. We took slightly different approach to hardware acceleration compared to companies like Succinct and Risk Zero who first mastered the VM design and are now adopting all of these 4090s and 5090s.

And then on the other side in comparison to our ASIC competitors, we did very heavily investigate hardware in the beginning but we decided to implement a lot of cryptographic stuff internally as a sort of breaking down the performance of the proving stack across the layers. So I'll actually start top down. We are really working on vasom based uh interface for our VM. We just last it call Jim presented Petra VM which is now an open-source VM based on a custom ISA.

So just for clarity this is not risk five and we have transpolation in between wasn't and custom ISA being developed as we speak. Now Petra is described in language called M3 that Jeremy mentioned. This is a new arithmetization framework for binus and binus is a proof system which is also open source developed but primarily developed by irreducible and binus is uh slightly different that all the other proof systems that these real time risk fs are running on. So unlike other proof system that are leveraging prime fields and frameworks like plonky 2 and plunky 3, irreducible runs in binary power fields which are in our opinion way more

hardware friendly and pro provide higher computing density. Venus was from the get-go designed for proving at scale and we see we are actually very excited to see a bunch of companies now adopting cluster scale proving. So we are outside of the spec of a single server and everybody's talking about clusters. Beus was designed for clusters from the get-go. And ultimately binus operates on atom cores. Atom cores are another custom ISA this time really like in hardware similar to ones that came out of you know fabric and other companies to mention them. But this ISA operates in binary tower fields and today we have it running on FPGAs at 450 MHz. One thing is that in Q3 we are planning to

have end to end basically acceleration wasn't to silicon and uh we will be releasing two things in parallel. One is our proprietary uh acceleration running on super microservers with eight FPGAAS but also and this is probably a bit of alpha today we will be releasing an AWS image so that all people who are interested in improving on top of be news can actually take an image run it in AWS and enjoy the benefit of this custom computing. This is really community effort in terms of helping others adopt BU. So you know for the future projects who want to work on this that's all. Thank you.

Thank you so much Radi. Uh and by the way congratulations to the 121 participants who made it through two hours of content. Uh I actually have a call starting uh very soon. Um so I'm hoping to to to wrap up. Um but uh yeah I'm not seeing any questions uh in the chat. So um I'll move on to to the to the to the next speaker uh which is um Sloan from Pon. Hello everybody. Glad to be here today. I'll present actually uh crypto

ASIC Proving: Ponos

CPU our newly released newly actually announced product. So briefly about the trends we've all witnessing a ZK centric Ethereum road on the other side we've seen a lot of progress in different kind of zero ZK proving algorithms and what is very important to state is there is a kind of uh convergence in these kind of trends mostly around risk five instruction set for witness generation as well as around small fields uh plus utilization plus aggregation uh for memory actually um better memory utilization and after that proof aggregation anyway all these kind of algorithmic progress

as well as progress in programming optimization with respect to mostly GPU have their limitations and beyond that point it's practically only custom hardware that may help especially when it comes to uh latency uh in which is crucially important for realtime proving so when it comes to crypto CPU we are taking a to be different approach. We are relying on high highly flexible risk 5 architecture and we are extending it in two directions. One is practically um custom uh um instruction set architecture for native support for risk 5 based trace generation and on the other side for support for uh prime field arithmetic op uh operations. Um on top of that actually we we plan to uh we

already developed set of co-processors that are uh supporting special function units for is for critical models and oper prim cryptographic primitives like entity hashing and so on and by the way given the trends I mentioned before everything is completely hard software code designed so that it's practically adopted for uh segmented proof generation and uh aggregation that sense uh it's very important to say that uh the beauty actually of this solution is that the fact that risk 5 architecture is general purpose CPU so that it which practically means that we may optimize existing standard compilers and uh

provide possibility for w um for um developer community that is widely adopting high level programming languages like rust to use it without any uh kind of problems. Um yeah it basically some benefits that it brings. It eliminates all kind of data bottlenecks that we've seen so far. By the way we have been developed solutions developing solutions in FPJs and we encounter a number of problems that actually motivated us toward making this kind of solution. um all um single modules and elements of proof are accelerated on one side but on the other side this f we have we are providing flexibility when it comes to programming

as well. Uh the platform may function as a cloud-based service but as well uh as a standalone device which is a kind of deepin enabler and as well as can be implemented on um on onrem infrastructure solution. So it's uh versatile and with no no migration cost. Uh we hope to deliver more than 10 times speed up compared to uh state-of-the-art solutions and not only a speed up but also to cut cost significantly and uh for instance if implemented in form of clusters we expect huge improvements compared to state-of-the-art and looking forward to collaborate with everyone in

the community. Thanks. Thank you so much. uh slowbo and I am looking forward to all of these A6 reaching production uh and at that point we will probably have a dedicated call uh just for stock A6 but it's a bit too early right now so that was the end of the A6 section we just have two final speakers before we wrap up uh and so I'd like to invite um Vanish from FMA And so that's going to be a quick section on distributed proving. Um, and the idea here is that

Distributed Proving: ZkCloud

not only can we improve power by having better hardware, but we can also improve the the power footprint by spreading the power across multiple uh clusters. It's possible Vanish had to go to a call in which case uh let's close off with Norbert from Z Cloud. I I'll go after Norbert. Hi everyone. Can you hear me well and see my screen? Yes. Okay. Amazing. Um thank you. So this is Norbert from ZK Cloud. Um thanks for sticking in the

call uh all of you who are still in. Um we are building the first universal proving infra for ZK supporting any risk 5 ZKVM. Um so this means we are flexible to swap as the performance of the different ZKVMs evol evolves. Um we've been participating in ETH proofs since late March and are very committed to supporting the snarking journey of Ethereum. Um, one of the things we've been doing since the 1st of April, um, proving every Ethereum block, um, it's running with single GPU. Um, and we are basically posting all of the proofs to the ETH proofs staging interface. It means um basically in the past seven

weeks we've proven about uh 380k blocks uh with an average proving time of of 1 minute and 8 seconds or something like that. Um our current infrastructure um is basically a cluster of 24 490s uh but we've got the capacity to scale to 200 GPUs um same 4090s uh as needed and probably as I hear it's going to be needed to facilitate real-time proving um in the first days but then we'll see how things evolve. We are currently using a custom version of RSP um SP1 for proving and um multiGPU proving coming soon. So

that's something we are actively working on. We are exploring other ZKVMs um that are open source and also have the the multiGPU implementations open source. And regarding GPU pro uh sorry regarding real-time proving uh as soon as open-source ZKVM and orchestration implementations are out there um we are going to switch and happy to start realtime proving as well. Um along with the others um yeah I think that's it from my side. Uh yeah happy to take any questions but I think we are a bit over time. Thank you. Nice. I think my main question is uh since Riser's um

kind of cluster multiGPU code is open source, are you considering them as a next target? Absolutely. I mean we've been exploring Risk Zero. Um they came up with R0VM uh 2.0 sometimes sometime in April. I think that's when it was open sourced um while SP1 came out with Turbo in January. So that's how that's why we initially went with SP1 but actively exploring risk zero open weathers as well. Perfect. And thank you so much for being an early proofs integrator. Thank you.

Distributed Proving: Fermah

Next up we have an closing talk uh Vanishes from Ferma. Thanks Justin. Um we are a universal proof market. I have two updates um on CKVM integration. We have integrated with ris zero and openvm um and are locally generating proofs for risk zero and other zkvm integrations are in the pipeline. Um looking forward to soon submitting proofs um uh to eat proofs. Um our near-term goal is to uh integrate pretty much all CKVMs and uh submit proofs for some of the most uh performant ones. Um on another topic um we have an update on the research side

of things. Um we are looking at the gap in um in the security definitions of uh proof systems. Um so the current uh situation is that the best uh formulation of soundness um is for ZK Snarks is uh simulation extractability. Um but this this formulation th this um definition assumes that the proof system satisfies zero knowledge property and most ZKVMs are not built with uh the zero knowledge property um as a focus and um we don't have a proof uh we don't have a

definition um against which you can prove uh security for proof systems in in a in a proper manner in in in in the best possible manner. So we are proposing a new uh definition. So coming up with this definition is not trivial. Some people have already uh have been looking into this. Researchers have been looking into this and we have a proposal and we call it chosen uh proof uh extractability and uh Alex um from the Ethereum Foundation has kindly reviewed it and uh uh if anyone else is interested please DM me and happy to uh share it and we will publish this soon.

Thanks. Amazing. Thank you so much, Evanri. And it's an interesting combination where I believe you have the the strong academic background and you're working on the distributed provers. And so there's this interesting mix of uh snark security definitions and integrations with ZKVMs. Love it. This was the closing talk. Thank you so much to the 100 plus people who made it to the very end and I'll see you all next time for call number three. Thanks guys. Bye.