Ethproofs Call #1: zkVMs

Transcript

Introduction

Hello and welcome to EF Proofs call number one. Uh we are one minute past the hour and we already have 100 people in the chat. We're expecting about 150 uh people today and um it's going to be an extremely busy call uh packed with alpha hopefully and it's going to last a little bit longer than the calendar invite says a whole hour and a half. So if you have to drop off at the hour, that's no worries because the uh call will be recorded and put on YouTube. So I have a little presentation that I will kick things off with and I'll try to keep it as brief as I can.

So um this is call number one and we're going to be uh focusing on on ZKVMs. If you'd like to join the community telegram group, the QR code is in the top right. And if you'd like to follow us on GitHub, everything we do uh is open source and has been open source from day one. And we uh most welcome uh pull requests. And if you're not familiar with EF proofs, the oneline summary is that it's L2 beat but for ZKVMs, at least for ZKVMs that can or at least plan to be able to prove EVM blocks.

Now the reset uh of uh e proofs is to accelerate ethereum stockification. The key primitive that we're trying to unlock here is is real-time proving. And that's going to have consequences at all layers of the Ethereum stack. The consensus layer, execution layer, and application layer. At the consensus layer, um real-time proving allows for postquantum security. That's one of the features of of the beam chain. Basically, it allows us to recursively aggregate hashbased signatures. Um, real-time proving also unlocks validators on extremely weak devices like phones and and and and watches. And you can even have fully validating nodes uh like wallets that

are not validators also benefit from that. Um, one of the things that um I think many people are very excited to see on on Ethereum layer 1 is a very big increase to the gas limit. you know, not a 20% increase, but you know, orders of magnitude increase. Think a thousandx increase. And this is only going to be possible once the validators verify snark proofs of validity of EVM blocks as opposed to having to re-execute. And very much related to increasing the gas limit is the notion of native rollups where um the rollups can directly access L1 gas and that comes with all sorts of security benefits. And finally uh the last big unlock from real-time proving is this

notion of synchronous composability where different rollups that share a sequencer uh can synchronously compose and in the context of DeFi you can do things like flash loans um you know atomic arbitrage and and and liquidations which is something that you can't do uh in the asynchronous uh model. So here's the tentative schedule for 2025. Um call number two uh will be dedicated to provers. Um so we have 21 ZKVM teams that will be presenting today and we're going to have a bunch of teams on the prover side of things that will also be presenting on call number two. Those are teams that are uh actually running the

Schedule

machines uh to to do the proofs including for example Snarkify and ZK cloud that has integrated with Eve proofs. Uh call number three will be dedicated uh to bringing the L1 to to the gigas frontier 1 gigas per second for the L1 EVM. And then course four and five will be dedicated to this big question of what kind of ISA if any do we want to enshrine at the EVM at at the at the L1 to replace the EVM. Should it be risk five? Should it not be risk five? Should it be something else?

uh and then um call number six will be dedicated to to formal verification which is an extremely important topic. Now the rest of the call is split in two parts. First of all, I'd like to give some updates on if proofs and then secondly I'd like to invite the 21 ZKVM teams to to present including three ZKVM teams uh that have that have not re publicly unveiled their their ZKVMs publicly uh until this call. So um before giving uh updates I want I do want to give a quick shout out to the team that actually built E if proofs uh Nuno Pablo Paul and and Joshua they happen to also be the team behind

Team & New Features

ethereum.org or and without them uh e proofs would not have been possible. So thank you and as we're speaking right now they are actually building a v2 of e proofs uh and I want to give you a taster of some of the the features coming in v2. So one of the the new features is multi-achine proving. Right now on e proofs uh proving is limited to one single machine. That means one single CPU and one single GPU. Um and if we want to unlock real-time proving we're going to need several CPUs and several GPUs. Uh hence the new multimachine tab. And we also want to be extremely transparent about the hardware

that the provers are are running. And so we're going to have all sorts of gory details on the actual specs of the the clusters that are doing the proving. Another um feature introduced in v2 is uh pizzas. So every ZKVM very similar to L2B will have a pizza where every slice represents a specific uh property and it can either be red, yellow or or or or green. And if we zoom in to the the pizza slices, there's eight of them. The top two here are performance pizzas. So verification time and proof size are important. And then

the the bottom six here are security slices. So the the left three are related to auditing and formal verification. And then the right three are miscellaneous security properties such as how many bits of security are you targeting? Are you postquantum secure? And do you have a bounty program? And if so, how large is it for critical vulnerabilities? Yet another uh feature of V2 that I'm very excited about is in browser verification where proofs uh will be uh verifiable with a single click within the browser. Um and I'd like to invite uh Farah to the stage uh to to share her screen to give us a little demo.

In-browser Verification

Great. Thank you. Isite verification also intended for V2? Yes. Um sorry aside sorry um not yet but if anyone wants to build it uh we it is something that we would like and uh a poll request would definitely be welcomed.

Okay. Yeah. My name is Farah. have been working with the e- proofs team to get um proofs verified in the browser. So we just have a proof of concept working. Uh we engaged Paul Miller and his micro zk proofs library currently that supports grath 16 and plon verification. So we're kind of downloading and parsing the ZKM proof right now um and running it through kind of just like some parsing function so that it can be consumed by his gra 16 uh verification function um and then I'll run just kind of like the demo here of the proof of concept where it's going to download basically when I click on the button to to verify it the proof that the teams have uploaded and

it will verify the proof in browser and then show the time in milliseconds And so it's like really great, really fast. And we're hoping that teams will kind of reach out to us and get kind of their proofs verified in the browser and we can get it implemented and yeah, great. Amazing. Thank you so much, Farah. And this 43 milliseconds is an actual time that it takes to verify a ZKVM uh graph 16 proof on a single thread uh in a browser. So expect those times to improve uh uh quite dramatically.

Okay, let me get back to the presentation. So, the other feature that I'm super excited about is this notion of of prover killers. So, not only do you want to prove mainet EVM in the average case, but we also want to Ethereum to be robust against the worst case blocks. And killers are basically uh specially crafted EVM blocks that try to be as hard as possible for the the provers to digest. And uh here what we're suggesting basically is a 2x2 matrix where every column is a prover uh and every row is a cluster of of machines uh running a specific ZKVM. And if you can get under the 12 second mark

then you get a little green uh notification. And here I'd like to invite uh Connor to the stage uh who is crafting some really nasty uh prover killers uh for for e proofs. Uh Connor, the the stage is yours. Hello everybody. Uh my name is Connor. I'm uh call me an independent researcher. Um my special interest right now is prover killers and uh this was born out of a project I did recently called ZC carnage which was designed to stress test the ETH proof provers by uh strategically submitting kind of malicious transactions. Um the goal here is to sort of exploit the

Prover Killers

asymmetry between EVM gas cost and the ZK prover cycle counts for certain operations. Um, and the initial batch of proverkillers were releasing to the wild are well-known expensive and ZK unfriendly features of the the EVM. So, Shaw 256, Catch, uh, Mod XP, EC recover, and elliptic curve pairings. Um, we know that the rapid pace of innovation that everybody's uh, doing here combined with a concentrated effort on these painful scenarios uh, is going to bring these provers to justice.

Um these uh test cases are going to be distributed via the Ethereum uh foundation existing test repository. So um I know a lot of you are sort of plugged in with that already. Um we're going to be doing our best to distribute these in a variety of formats that are compatible with existing testing suites and uh we'll be following up with how you can submit solution benchmarks against these particular scenarios. Uh thanks see you in the wild. Amazing. Thank you so much, Connor. And I really want uh one of your hats. Uh special prover Killer hats. Yeah, if you're going to be in uh Toronto for ZK Summit, I'll be around and I'll have some if anybody wants to find me. Nice.

And we've tried to give every prover killer a cute name like Shy 56 Slayer and Modep Murderer and whatnot. Okay. Um another improvement that we like to have on on Eve proofs is much faster data fetching. So if you go on the website right now, you'll basically see two columns. One is total time to prove. So that's the time it takes for e proofs to actually receive the proof. And then prover time uh which is the the time where the the zkvm is actually doing its magic. And most of the delta here is related to what's called data fetching where you need to take the EVM block and go prepare all of the uh storage proof.

Proving Time

So every time you read and write to the EVM uh state, you need corresponding Merkel paths. And that takes a very long time, sometimes even more than the the the proving time. And I'd like to invite uh Kev to the stage to basically tell you how to do it the proper way as opposed to using uh alchemy which might be very slow or an archive node. So Kev, the the stage is yours. Um yeah, hello. Can you hear me? Yes. Um yeah. So I guess to be quick the the better way to do this is to if you're using ref just call the debug execute witness uh RPC endpoint and this will

get you uh a multi-roof that proves all of the state accesses for a particular block instead of calling if get proofs uh which means that you need an account proof uh per account that's touched. Uh so it's one RPC call versus like n where n is the number of accounts touched there. Amazing. And this is a a normal refle archive node. Right. Right. Right.

Okay. Perfect. Thank you, Kev. So hopefully yeah these these two numbers should be converging and the data fetching should really take less less than a second. Okay. Uh next up we have uh some real time proving grants. So ultimately the goal is to prove every single Ethereum block in real time. So that's under 12 seconds and across a variety of of ZKVMs. And so in order to um incentivize that, we will be uh launching a grant program. So that's three times $100,000 uh dollar grant.

Real-time proving grants

And we're going to launch this on call number two. And I'd like to invite Alex Hicks to the stage to share a little bit more about the program and the eligibility. Yeah, thank you Justin. Uh yes, so some of you will obviously know that uh DF is doing trying to do its part in helping ZKVMs be full formally verified. We're also very excited to try and do our part to help ZKVMs push performance as much as possible and also to showcase their performance. Uh so what we'll do is we'll basically be offering out some grants to the best ZKVMs in terms of their performance to try and support you know real-time proving over a decent period of time like a year. Um there'll be some kind of clauses around you know

having an open source prover uh being you know within a silent threshold of real-time proving on on a more modest machine and things like this. Uh there'll be more details to come but uh yeah everyone can look forward to that and if obviously you're developing a ZKVM uh you can start warming up and trying to um increase your performance and and compete with everyone and try to be some of the top three ZKVMs. Amazing. Thank you Alex. And you know because this is a grant for the provers um we will be announcing the the full rules and eligibility on call number two dedicated to provers and then final slide in this first section I'd like to uh introduce

Ethproofs Coordinator

and invite uh Will Cororan uh who has been doing a fantastic job you know accelerating um a lot of the coordination task uh to to to make eeroofs um develop so fast. So if you need anything, he he's the the first port of call. Um he can help with API keys, intros, bug reports, uh you know, grant applications, calendar invites, you name it. Uh and I will uh invite him to the stage. Will, thanks, Justin. Uh yeah, great to meet everyone. uh just here to help keep everyone moving and unblocked and connected and uh connect people externally and internally with uh

EF researchers, the uh ethereum.org team if you have feature requests or anything that you uh want to communicate back to the team. Uh happy to make that happen. And yeah, just really enjoying this whole process so far. Fantastic. Thank you. Will uh Will only joined us a few months ago and he's already uh doing wonders. Okay, part two uh ZKVMs. Um so here is the list of 21 uh teams that will be speaking, three of which are new. So what I'd like to do is have these three new teams speak first uh and then we're going to have the 18 other

Intro to zkVMs

teams uh provide uh updates. So, the new ZKVM uh project speakers are going to be John from Argument, Maya from Stockware, and Jim from Irreducible. And the ZKVMs that they're going to present are called X Stock 5 and Zray. So, I'd like to invite uh John uh to to the stage. Hello. Can everyone hear me? Yes. Okay. Let me share my screen. Okay. Is this visible to everyone? Yep.

Ix by Argument

Great. Um, hi everyone. I'm John from argument. Um, and uh I want to give everyone a quick preview of our um uh new uh uh functional reduction zk work which is the latest iteration of our previous work on lurk and the atima compiler. Um the goal of this project is to uh explore an alternative architecture to creating ergonomic general purpose CK proving that avoids the uh hardware ISA uh abstraction and therefore the complexity of um uh compilation stacks like uh LLVM or the rest compiler which are not uh designed for the proving context and may have uh

some uh security issues. um uh in the ZK context that don't really appear uh outside of uh ZK. Um we also want to support uh formal verification natively and um the uh so instead of uh proving the execution of um an assembly-like uh model we are directly proving the execution of the lean 4 uh kernel which is uh a very simple language um but uh so essentially a dependently typed lambda calculus it's not really a whole lot more than lambdas as um pi types and inductive types. Um and uh what's

interesting about this is that this allows us to plug into the growing ecosystem of lean for libraries including the EVM u lean formal model of the uh of EVM execution and this is how we plan to get uh to ethroof's integration. So by taking this uh executable functional model um in lean 4, we compile to a uh an anonymous and alpha invariant content address representation and then we um use a new functional ZKDSL uh that um allows for translation of functional programs into the binius uh backend. Um we uh believe that this will also have some interesting uh

performance implications. We uh are not at yet at the point of predicting you know where this is going to land with respect to performance you know with a lot of these other really great projects that a lot of great optimization work has happened. Um but at the very least these will be orthogonal optimizations to a lot of what um people are working on here and we think that that may be may be really useful. So the first goal is really safety. Um and then you know exploring these uh other optimizations for uh you know static and immutable memory. Um what's uh what's interesting about this is that you know when we prove we're not really proving you know a memory state and the uh the sort of dynamic um you know mutation of of you know memory like you like you're uh modeling a CPU. We are basically doing

graph reduction. Um and this this is this is pretty interesting how this interacts with the uh proving back end. Um the other cool thing about this is that uh there are starting to be uh formal models for other languages in lean like um Anias. And so this will also support writing zk proofs in rust as well as well as uh taking uh not only proving the execution of um of functional uh code but also proving its type checking so that uh you can get a compressed ck proof not only of the execution of your program but also that all the formal uh properties and the types uh were correct.

Okay, John, thank you so much. Um and just as a heads up to the next speakers, uh I'll have a timer uh around 2 minutes. Uh but yeah, one of the things I'm super excited about um this this project is that we have an implementation of the EVM in lean 4 that the Nevermind team uh built. And so we could potentially have proofs of the EVM that don't rely rely on compilers, don't rely on on on on circuits. uh and it's kind of uh provably correct uh at least at the arithmetization uh layer. Oh, you can't hear me. Can you guys hear me? Yep, we can. Okay,

perfect. Next up, uh we have Maya from uh Stockware who will be talking about uh Stock Five. Um yeah, hi. So, should I share my screen? Uh yes, please. Oh, let me do that. Sorry. Really sorry about that. I didn't know I was supposed to share. No worries. Yeah, my bad. There we go.

Okay. Share. Okay. So, I hope everyone can see and hear. Um, so I'm presenting Stark 5. The name is not final so don't get attached. Um it's based on the idea of implementing risk 5 errors for stew. STU is darkware state-of-the-art nextgen prover. It beats in benchmarks all other stark and snark based provers out there. Um I can share some uh some metrics. Um it's based on ky. So we have Cairo errors for the STO prover now and all our benchmarks are based on Cairo and we truly believe that the Cairo VM is the

StarkV by StarkWare

most optimized way to achieve fast proving and create traces that are cheap to prove. However, we know that risk 5 and rust are very popular and uh we do want to supply at least for client side proving or projects like ETH proofs uh to be usable to users. So today there's an airs by nexus for risk 5 and uh so this is an ongoing project and we are in collaboration with them and we plan to hopefully in the near future have additional custom errors that we develop to either add to or completely from scratch create uh the option to prove

rest. Um so again the pros are it's easy to use a wide adoption. Uh we do also truly believe that we want to decentralize the technology around stew and starburst technology in general maybe in the future support multiVMs on startnet. Um the downsides of course are it will be definitely slower than Cairo and Cairo M31 which is our next generation uh airs for stew which have a 50x expected optimization over even Cairo and yeah that's it looking forward.

Amazing. Thank you so much Maya. Uh and it's I think amazing to see you know the grandfathers I guess of of ZKVMs uh you know starting with tiny RAM in 2013 moving to Cairo in 2021 you know you know moving in this direction of of of Rust and RS 5. Uh super exciting. Uh we do have time maybe for one question uh for for Mayo. Feel free to uh raise your hand otherwise we'll just move on to the next speaker.

Okay. Uh, next speaker, Jim from Irreducible will be presenting Zray. Jim, the floor is yours. Yes. Um, hey, I have one slide. Okay. Um, we are working on the Zray VM. Um this is a temporary project code name. It will get renamed very soon. So this is an early preview. Uh this is a binas native verifiable VM. Uh so it has a custom ISA optimized for binius arithmetization. That's um what we're

zCray by Irreducible

building. It has three primary goals. So first we want it to be low overhead um enough so that we can implement binas recursion efficiently. We're implementing Binius recursion as a program in a high level language called ZrayML which is an SMLbased functional language that will compile to uh the VM instruction set. The second goal is we intend or we're building a pipeline for compiling Rust to web assembly to Zray uh Zray assembly. So any web assembly module we want to be able to prove using this VM architecture and by extension that would be able to be capable of proving rust

programs. And the third application for this is that we believe this will be lower overhead for um highly specialized use cases where you're also willing to write uh where developers are willing to write this functional highle language ZrayML and we want interoperability with another VM. So we're designing it so that if you had a risk 5 VM built on binius that it would be able to dispatch calls to uh to the ZRA VM. Why do we think this is low overhead? The techniques we're using are nondeterministic ROM um binered by Cairo and then we don't have general purpose registers. Uh there is an optional RAM extension, but for certain applications,

you might not need readwrite memory and be able to get away with only the the ROM. Um and we're building this in collaboration with Polygon, expecting the recursion program and uh high level language in June and the RustWom compiler in Q3. Amazing. Thank you, Jim. Uh any questions please raise your hand. I do have one immediate question. Sorry for asking it. Uh when open source um soon with a capital S. Uh we're trying to get a name and then uh we'll start building in public.

Um I within a month certainly I think it'll be sooner than that. Nice. Q2 as well. Same as X. Lev you have your hand up. Uh yeah a very simple question why variable construction in coinc um uh because we can do that efficiently and um I don't think like I guess basically the cost of having larger programs is not the primary cost and so you can um basically fit more logic by having larger instructions uh and and

minimize trace size in certain cases. It's a nice amount of flexibility and I'm basically not worried about like rop programming attacks because it's a harbor ar hard harbor Harvard architecture and we have another question in the chat. Is the ISA stable or are there still tweaks going on? Um there are still tweaks. I mean it's mostly like additions. So we're adding instructions as needed, but the kind of core architecture of it is pretty much designed and stable at this point. Amazing. Thank you so much uh Jim for this. Yeah, super excited about

about Zray. So let's go back to my presentation. So this is kind of the summary slide. We're unlocking lean 4. We have this evolution from tiny ram to cairo to stock five and we have this collaboration around binas between irreducible and polygon with uh zray. Um so now I'm going to go back to my list and invite uh Michael uh from matalabs to discuss uh budum 2.0. Uh hi guys, thank you Jake or thank you Justin. Uh can everyone hear me?

Yes. Okay, excellent. Um, just share my screen. Hi. So, um, I work on the GPU provers at Matter Labs, uh, for a few years now. And I'd like to say a few words about our, uh, new Bougen stack. Uh first of all we have this new execution environment um multi-interpreter that offers uh native EVM equivalents to developers uh and we compile it to risk 5 for proving with with uh Bougam 2.0

Boojum 2.0 by MatterLabs

which is uh what we care about the most today. Uh BJM 2.0 know is our new Stark prover uh uses air constraints uh based on an M31 field. Um and we prove uh a risk 532 um I plus M instruct excuse me instruction set um and we do have some delegation circuits as well um and the cool thing about it is that it's fully GPU accelerated end to end and here you can see a GPU timeline that I've broken down that shows you know how comprehensively we have written uh and hand optimized in-house CUDA for almost all of the provers's operations So um what's the payoff? Um I can

present some uh preliminary performance numbers. Um here's the raw segment proving speed that we achieve on um various both commodity and data center hardware. Um this is a super rudimentary benchmark. It's it's just the segment proving. um it doesn't include uh memory pre-commitment or recursion or um account for delegations. Uh we do have all of these pieces. Uh we're still just gluing them together such that we can run that all run it all in one shot. Um and also these numbers do require uh pretty beefy beefy support from CPU cores to uh to feed the beasts so to

speak. Um and to simplify that we are moving uh witness generation to the GPU which my boss Robert Remen is working on. Um which will uh make everything much more streamlined. So these are rudimentary numbers but uh they're very promising um and I've estimated for honesty um the impact that we expect to see from the memory pre-commitment and uh the GPU witness generation based on running stuff standalone. Um, and you may notice that from a month ago to today, uh, performance has gotten slightly worse on some of the beefier cards. Um, and this is because for production, we, uh, we target best performance per dollar, which is currently delivered by, uh, L4

GPUs as far as we can tell. So, um, some of our optimizations that were specific for L4 actually, um, hurt the saturation on the bigger cards. But we can easily target uh we can easily tweak the code to target any uh data center or commodity hardware depending on where people want to run these proofs and how decentralized we want them to be. Um so I've also anticipated uh a few questions uh from you guys. Uh can we prove uh mainet EVM blocks? Um yes. Again we're still running the components separately and gluing everything together. Um and we're also running in Bjam OS so far which has a it's a type two uh EVM so it has a different storage model but a

rough estimate is uh 2 to 3 minutes for a block on an L4 or uh 35 to 50 seconds on uh the beefier 5090. Um and when open source same answer as everyone else soon uh we are still we everybody wants to open source it but we're still internally discussing how polished we want it to be uh and when ETH proofs uh currently we're all quite busy um getting Bougum deployed um to power the ZK single elastic network um but you guys have our DMs and uh you know we're talking regularly so let's just keep that

Um and I've also provided a link down here to uh a more comprehensive talk about um BJ OS and BJM 2.0 uh capabilities and imple implementation and then uh references to um a couple of researchers who have informed and greatly helped our work. Um yeah, that's it for me. Any questions? Amazing. Thank you so much. Uh, Michael, you've already answered coincidentally a lot of the questions I had. We do have one question in the chat. What is the proof size roughly?

Oh, the proof size. H uh, you know, I don't know off the top of my head. Um, we we have, you know, we recurse down to, you know, we start with a bunch of segments. Uh, we we do have recursion. So we recurs down to a single snark proof or stark proof rather. Then we wrapped that in flank for mainet. Um and I don't I I didn't work on the fanc aspect. So I don't know uh what the final proof size is there unfortunately but I can I can post that information send that information to you guys on telegram later. Yeah for sure.

Ceno by Scroll

We have the e proofs community telegram group. We're out of time. Thank you so much Michael. Next up, we have uh Ming from scroll who will be talking about CNO. Sure. Am I stopping? Yeah. Can everyone hear me? Yes. Yeah. Thanks, Justin. And hi. Hi. Hi everyone. I'm Min from scroll. Yeah. So, uh today I do a summary for the Senov VM. So, Senovm is a a joint effort with PS in the beginning. So then later I join scroll to dedicate to explore the theoretical bound of the seno VM. Yeah.

So basically in seno VM what we highlight the sre is all all you need is we we try to build some VM which bas on some check only and don't do anything else because some protocol is the most beautiful protocol with a linear time. Yeah. So few highlight for the seno VM first is we build on multiari some check and for the circuit part we do a gkr layer circuit to have a less commitment and we also use a lock up to to handle the continuation between circuit. Yeah. So we do it on a small field and we also do it on the hashb pcs and another highlight is the prover is only pay as you go. P you go means that uh according to your different workload and uh the prover will only do the work you needed

without any like a traditional padding we needed for some other kind of the provin system. Yeah. So this is another highlight and we are built on top of the PL3 and for the performance uh perspective uh we benchmark on the the without ABS on the CPU because PR3 have a limited support on goldilock so we cannot test on the ABS for now and uh right now we can prove one block uh one block is like a scroll manet block but scroll is a type one EVM so it's a fully compatible with the Ethereum mainet uh no spec different and right now proof one minute block can be less than 1 minutes in on the modern hardware without like hardware acceleration on CPU and also we test some different various workload for example some

typical workload we care in the ZKBM benchmark we can out perform some state-of-the-art with 1.5 to 2x even we turn on the ABS on the the state-of-the-art candidate we still can outperform so it's pro promising now and regarding the less of the develop road map is the first is the we 100% open doors and right now We working on GPU acceleration and we target to roll out on the uh 2025 the second half with the it proof on boarding once the GPU request ready. Yeah. So let's see from me any thank you bank uh one minute proving time uh without GPU acceleration is extremely impressive. Uh what is the

gas limit uh the gas usage sorry on that that one minute uh benchmark? uh we don't measure gas limit now but uh because scroll manet is a specialized uh like we it only include one or two transaction so it's kind of the ting block compared with the mainet yeah so uh we we yeah sure but we test on proving one complete magnet uh block from the L1 it can be less than 10 minutes for now without any hardware acceleration so if if we enable GPU I guess we could can get more promising results okay Perfect. Any questions, raise your hand.

Otherwise, we'll move on to Roit, also from Scroll, uh, who has been working on Uklid, Ro, the floor is yours. Uh, we can't hear you. I think you're muted. Sorry, I was on mute. Um, yeah. Um uh I just want to clarify that Uklid is not a ZKVM but uh it's scrolls um most recent upgrade where we deprecated our Halo 2 based ZKEVM circuits in favor of uh uh uh ZKVM which is uh OpenVM. Uh there is um um I see in the in the agenda there

Scroll zkEVM by Scroll

is uh OpenVM's presentation as well. So we'll go into the we'll go into details But um for scrolls layer 2 um the the benefits we achieved by transitioning to um a ZKVM uh which were also originally the motivation was uh firstly more compatibility where um we could deprecate our Poseidon hashbased ZK tree in favor of ML Petricia tree. Um secondly um our circuits Halo2 based circuits were extremely complex.

Um so it was hard to um test, hard to audit. Um we could replace them with uh much more readable uh Rust code uh which are guest programs for OpenVM. Um uh we can now achieve uh support for new EIPs and rollup improvement proposals significantly faster than before. Uh and an example of that is that with this upgrade we also have support for EIP7702 and um uh RIP 7212 uh which was I I believe we could u add this integration in less than a week

which is which is um uh proof that uh it's helping us in um um supporting our IPS much faster. Um we also have uh much more performed prover now um uh using openVM um for the EVM layer itself um compared to the previous uh previous version of scroll which was Darin we already have uh proof generation for that which is three times almost three times faster um um in terms of proving costs uh I've mentioned that uh it's around uh 1.2 2 cents per mega gas and um of of for scrolls layer 2 blocks and

uh as a result of transitioning to ZKVM we could also deprecate one of our um components which existed before which was called the circuit capacity checker uh which limited uh certain transactions on scrolls uh mainet because of the limitations due to Halo 2 circuits and are degree bounds. We are um um open source. Um the ZKVM prover repository basically includes all the guest programs, the proverifier codebase. Um and then we have uh a separate tool for stateless verification of EVM blocks. Um um and we we basically

use uh our EVVM and we f that to um to uh improve um uh to improve the uh risk 5 cycles for some uh some of the uh some of the pre-ompiles EVM pre-ompiles uh by using OpenVM extensions. Um in addition to that yeah we can already prove uh Ethereum mainet blocks but uh uh we have not yet published a report on that. Um and with regards to e proofs integration uh we we don't have this ready yet but uh we have um most of the components um already ready. We we need to piece them all together. So

probably in the in the coming weeks that is something we could work on. That's all uh from my side. Amazing. Thank you so much Roit. Um, in terms of the flow to integrate with EF proofs, step number one is to create the Telegram group with the e-roofs team. Then we'll give you an API key for staging. You can test the API uh on staging and then once you're comfortable with that, we'll give you a production API key. And so far we've had four integrations and uh they've all been uh very very smooth.

Uh, next up we have uh Jolt with Justin from A16Z presenting. Justin, the floor is yours. Hi. Um, yeah. So, uh, Jolt in a sentence. Um, it's a ZKVM, uh, that's uniquely reliant on the sum protocol and lookup arguments. Um, I think lookup arguments are a little bit unfortunately named. uh I think it'd be a little clearer um it's just a different perspective on them to call them batch evaluation arguments. So when you evaluate the same function many many many times lookup arguments uh are just very very simple uh very very efficient

proof systems uh for that setting. Uh they get rid of circuits. Um and so you know ZKVMs they evaluate the same primitive instructions over and over and over again. They're a perfect fit for lookup arguments. Um maybe I'll start calling them batch evaluation arguments. So uh Jolt has three core components. Um there's uh the uh memory checking arguments. Uh lookup arguments are equivalent to readon memory. Um there's of course VMs have read write memory registers and RAM. And then there's a a minimal uh constraint system in Jolt as well. Uh basically capturing like the fetch decode logic of the VM. Uh we are in the process of switching our memory

Jolt by a16z

checking arguments from lasso and spice to twist and shout. Um which uh you know our new memory checking arguments from a few months ago. Um so our current priorities are finishing the twist and shout integration. We're uh two to three weeks out from that. Um it's looking you know very very promising for significant speed ups and increased simplicity. Uh the priority following that will be to keep the prover memory usage bounded. Uh we're going to do this without using recursion. So a significant departure from how most ZKVMs uh keep their prover space usage under control. Uh that will probably take a couple more months to implement. So sometime this summer I

hope. And then the the final major priority is GPU integration which is in progress but you know to really squeeze it it's going to take a long time. Six months say something like that. Uh we're fully open source. We've been from day one. Um so that is Joel. Amazing. Uh thank you Justin. And I'm very excited about the uh the streaming without recursion. Uh a paper was published on e-rint uh just uh a week or two ago. uh and it seems that the the machinery needed to achieve uh small uh proven memory is uh much much uh simpler than the the recussion machinery. So

yeah, exciting new research which hopefully will spread uh beyond beyond Jolt. Any questions for Justin? If not uh we well if not thank you so much uh Justin and uh yeah looking forward to uh to having an end to end uh EVM proof on on each proofs. Next up we have Elas from Kakarot who will be presenting KEF. Thanks Justin. Should I share my screen? Sure.

Keth by Kakarot

Okay. I assume you can see the screen. Yep. Okay, cool. Hey guys. Hey everyone. Uh my name is Elas. I'm one part of Kakarot. So I'm um we're at ZK native. We call it ZK native as it's an implementation of the EVM in a ZKDSL cyro and targeting the two prover library of starware. So in five data points uh we started in late 2022 and at the time when we started it was the first uh EVM implementation that targeted a ZKVM and then as you as we've seen um ZKVMs are more using general purpose ISS today. So our journey has been a bit bumpy. We started as EVM in

starknet as a runtime on top of the starknet L2 then as standalone ZKVM rollup and now we are focusing on stateless L1 proving stack. Um it is the first alternative stack which means it's a new implementation of the EVM uh based on the ELS uh spec execution layer specification that it has no dependency on RVM risk 5 or plunky 3 which we think that's why we put in in in front the alternative part of it um in at least in terms of ZK client diversity and the work is quite nimble as compared to secrets it has taken four FT engineers over four months to design a fully stateless uh ZKL1 client and in on the way we built some

nice open source tooling. Uh one has been a fuzzing framework that takes uh the Python implementation of the Etherum foundation called ELS and diff tests it against uh uh ZKVM. We've built two implementation um two toy implementation of the KOV VM uh one in TypeScript, one in Google sheet and the KO testr runner. Um so I'd say the team is mainly focused on not like offchain proving based on the KO stack today and there's two prover soon on improves.

Thank you Elas. uh what would you say is the major blocker to uh to get to Ephroof's integration? It's actually not it's a very interesting blocker. It's um the traces we generate are um akin to what the other Ziki VMs are doing. So 1 billion trace length for example and that currently is slightly too large for the KO approver and the continuations have not been finished yet. So I think um yeah the main issue is that KO was designed as a at least with the first priority of being a smart contract language and onchain trace length is more uh in the realm of 50k 100k and our trace length is 1 billion. So we have

we're hitting new walls that need some uh some splitting and some trace splitting. So that's that has been a major blocker which prevented us from being on proof I'd say one or two months ago. Okay, got it. Well, congratulations on completing the implementation of the state transition function for the EVM and yeah, looking forward to Cairo VM implementing continuations so that you can have an integration with you proofs. I see Maya doing a a thumbs up. Um, okay. And next up we have Olivier from Linear talking about uh its implementation of the EVM.

Linea zkVM by Linea

Hello. Can you hear me? Yes. Okay. And can you see my screen also? Yeah. Okay. Perfect. Yeah. So, I'm Olivia from Lineia. We at Consensus. We are building uh have been building a ZKVM for a few years now. Uh what we have is a type 2 ZKVM which is based on the MIMC hash function. But we're also currently exploring to going towards Poseidon. In the meantime, our ZKVM is in production. We have a mainet that is live. We are directly arithmetizing the London EVM.

Uh and we're proving the execution of native EVM bite code. Um in terms of uh uh where we're going, we will be upgrading to Prague. We're actually currently upgrading to the Prague EVM and exploit uh expect to deploy the relevant hard fork uh uh in Q2 or Q probably Q3. Uh we are also upgrading uh and this is uh will happen in parallel and will likely happen by end of year. Uh upgrading to a type one uh architecture. Uh our entire stack is also open source. Um and let me just say a few words about our prover um and its performances. So we are using a vortex uh an arcane proof system. Uh our currently our producing vortex

proofs is rather time consuming. Uh it takes 20 20 to 25 minutes on CPU for an aggregate of um uh many blocks. Um we are uh changing towards a limitless prover architecture uh which will allow us to uh distribute the prover and reduce latency and uh actually yeah improve parallelization. We also changing uh the base field of the arithmetization. Uh this will happen in parallel to the upgrades towards Prag. We are transitioning to a much smaller field from the BLS field we're currently using. And we expect so for this part it's hard to say what performance gains we'll uh get from that but we expect expect that uh for

the commitment part alone it should be uh pretty hefty upgrade of um 50x and we target uh a 10 sub 10 second latency uh by that point. Yeah. Amazing. Uh yeah, less than 10 seconds latency. That that sounds perfect for real time proving. Uh any questions for Olivia? I guess one question I have is um are you looking to do GPU acceleration as well?

Um so this would be a question for Alex who is the prover guy in our team but it's been a topic of discussion. Um, unfortunately I'm not really knowledgeable about enough about uh that part, but yes, we are we are considering it. Okay, fantastic. Um, next up we have Michelle from Nexus who will talk about Nexus ZKVM 3.0. Hi there. Thank you for this opportunity. So Mr. Abdullah from Nexus.

Nexus zkVM 3.0 by Nexus

Uh just to give a quick overview of about what uh we've been doing at Nexus. So our Zikvm is uh is based on the risk 5 instruction set and uh we are now in our third iteration of the ZKVM. The first ones were actually based on floating schemes over cycles of elliptic curves. But uh the our implementation turned out not to be as efficient as we wanted. And there were several reasons for that. But in the current iteration, we decided to make a major rewrite and switch to uh aimization of our circuits and to work over small fields. and we

did uh part of this work in collaboration also with uh starware and uh we use PS2 back end. So uh one of the things that uh it took a lot of time to do the rewriting is that we had to formally specify all the circuits that uh that we are using and that was a bit of work but it turned out it to be a nice uh it's has been very useful going forward so that we can do further optimizations. Uh the RZKVM is fully open source. We currently cannot yet proof EVM blocks but uh because we still

have some type of limitations on the size of proofs that we can handle but uh we're currently working on support for large executions and uh and recursion and we expect to have that in Q3. uh so be uh in terms of ease proof integration I think that will have to come after uh we we build the recussion and support for large executions as for real time proving that was one of the questions that was asked to us for the moment we don't have a hard timeline on it but there are several optimizations and performance improvements that we're going to need to to achieve to uh to be able to implement to achieve

that goal. Thank you, Michelle. I didn't realize you guys did formal verification. Can you expand on that point a little bit? I apologize for the perhaps uh we formally specified we didn't use formal verification of our circuits. Ah got it. But uh this is one of the goals in the future by having the formal spec by having a form of a specification we can formally verify it.

Got it. Um Carlos in the chat asks what was the major decision point on ditching folding? Uh as I said, we actually uh like going over cycles of elliptic curves seem to have a a big in performance impact on on on our ZKVM. Our memory checking for sure was not optimized and that has changed also. And since we wanted to go to smaller fields, um we thought we decided to and we were in collaboration with Starkware. We decided for the

moment to pause the folding idea and perhaps revisit later. Got it. And Elas asks um what is the current speed in kilohz or megahertz of Nexus? Presumably that's on the single machine. It's on a single machine. It's currently around 15 kilohertz but this is because we're still have a single monolithic proof uh strike proof. We are working on generating uh separate uh proofs and and this will we expect additional speed ups and this is not does not take into account GPU

acceleration. So this is just a normal machine. Okay, thank you so much Michelle. Next up uh we have Danny from 01 Labs who will be talking about 01 VM. Hi everyone. Can you hear me? Yes. I'm going to share my screen. Can you see it? Uh yes. Yeah. Okay. So, hi everyone. Uh start the camera also. Hi everyone. I'm Danny Williams, a cryptography engineer at One Labs and I'll give a quick description of 1VM.

o1VM by O(1) Labs

Um so uh the Olympian is still a work in progress. Uh we also don't have uh many resources full-time resources on it. So uh you won't see many movement at the moment. But so the currently supporting instruction set architectures uh there are two there is the MIP 32. Why we decided by to go with this is because there was uh there was this the proposal by the OP uh by optimism and so we participated and so we made first the1 VM compatible with the um with the OP program uh that uh I mean the the program that they call the OP program uh and it was mute 32 and uh we recently

integrated uh risks 532 IM um uh support uh there is no core no pre-ompile so plain uh plain computation uh cys scores can be implemented on uh by yourself if you want uh but there is no active development on it and why we didn't continue is because we wanted to integrate with other tool chain and so for instance risk zero uh the restion that they've got might be interesting but we don't have any plan right now So on the cryptographic side uh so it's based on it's a turf based uh we use the cycle of curves pasta uh we use IPA so

not rested setup um the constraints uh for the front end are defined um in a say a bellman for for the ones who still use bedman um so the idea is the same you work by implementing a a trait in rest that is called the trait interpreter and for the back end is promish no subject caution polomial um so at the moment it's just a prom that you can make on each uh sequence and so we still working on the recursion aspect uh it's going to be a folding scheme based on nova uh so it's a

generalization of nova for arbitrary custom gates any degree uh integrating also the permutation argument and also lookup arguments we call it arabata uh main idea behind uh is uh to just generalize the the the computation of the cross terms any degree so that's also a work in progress um everything is open source by the way uh everything is open source even if it's not ready even if there are many fix um and the memory consistency check argument uh is going be what we call run lookup.

Um, so I am out of time. So there is no resist yet setup. No GP, no G no GPU acceleration. Uh, we stop yet at the moment the 1 VM work because we focus on the Mina protocol at the moment. Um, we still running uh every day DP program in our CI. Uh, no if proof integration yet and uh how we wrote the front end at the moment. uh would is the formal verification uh at the end. We think so. So, sorry if I thank you so much Danny. Um I guess one question I have

is is risk 5 more of a priority now relative to mess or are they both equal priority? Uh they both the same. So the interpreter is implemented. uh we just wanted to have risk 5 as um as a as an experimentation see how it was easy to implement a new uh a new ISA in in the 1pm. It was like more hackathon between two engineers at 01 and so it ended up going well and so we think that we can also extend to other ISA very easily uh based on the interface that we uh that we that we did. So it took us like four three weeks I think or two weeks uh to implement the the interpreter. Um

okay got it. So it sounds like you almost have a framework for implementing ISAs and you're you're starting with these two but you can implement more maybe Zray or others. That's correct. Yes. Okay. Thank you. Um, one question in the chat with Nova, how do you encode the whole EVM instruction circuit? Uh, so for each instruction, uh, we have a certain constraint. At the moment, we have one selector for each constraint and so we prove everything at the same time. It's very slow. We're going to change later, uh, in a way like like a supernova. Uh, so we still have to work on it. Uh so an idea would be to um yeah

we can discuss later but the idea is like super. Okay perfect. Uh next up we have E from Axium who will talk about uh OpenVM. Hey everyone, I'm E from Axium. Uh so OpenVM is a modular ZKVM framework uh which is explicitly designed for customization and extensibility. Uh so it's based on a novel ZKVM architecture we're calling a no CPU architecture because it removes the existence of the CPU trace and does not explicitly materialize the execution consistency.

OpenVM by Axiom

Um the result is that developers are able to build their own ISA by mixing and matching op codes from what we call VM extensions. Um to illustrate the stack, we've implemented the RV32 ISA and have Rust tool chain support. In addition, uh we've added uh extensions to accelerate uh all pre-ompiles that show up in Ethereum, including hashes, pairing, arbitrary Edwards, and wire trust curves, as well as big integer and modular arithmetic. Uh in addition, we're excited about a direction to enable programspecific VM extensions that can be put into OpenVM programs without the necessity of forking or modifying the core OpenVM libraries. And

we think this is an exciting direction for accelerating workloads like Ethereum mainet blocks. Uh so OpenVM is currently MIT licensed. that we just finished up an audit with cantina at the end of last month and as was previously mentioned on this call it's currently used to verify uh scroll mainet state transitions. Uh we're also able to prove arbitrary Ethereum mainet blocks uh over you know relatively arbitrary sample of 10,00 blocks. Uh we achieve subsent per mega gas cost and uh latency under 10 minutes on a single CPU prover and close to 1 minute on a multi-achine CPU prover. So currently we're working on a GPU prover and our plan is to go on

to ETH proofs and hopefully real-time proving uh once that is ready. And you can check out more information about OpenVM at openvm.dev. Okay, thank you. E, just within the time budget. Uh, any questions for E? Uh, one that I have is, um, can you share maybe other projects beyond scroll that are integrating with OpenVM? Uh, we're talking about a few other projects, but nothing to share right now. Got it. Um, and is it correct that the GPU prover is coming soon, TM?

Yeah, that's that is correct. Okay, perfect. Any further questions for you? If not, uh, we'll thank him again. Oh, there is a question maybe. Um, nope. Okay. Uh, next up we have Mo from Brevis who will be talking about Pico. Uh Mo, we can't hear you. Maybe you're muted. Yeah, I think I was muted now.

Pico by Brevis

Should be fixed. All right. Oh, okay. Um, thank you, Justin. Uh, this is Mo from Brevis and happy to introduce Pickle here, our open source RX 5 compatible ZKVM. uh they can already prove their east blocks east main life blocks. Uh so when we designed pickle we really had two uh goals. One is application aware and application centric and uh the other is future proof and the modularity was our answer really to both. Uh so Pico is now the only ZKVM that allows you to actually flexibly swap between different back ends with just one line of code

changes. All these proving back ends listed here are available uh for people to use. Uh this kind of moderate back end uh architecture really allow us to adapt any future development in the underlying proving system quite easily. And for developers they can just really adopt things uh you know and try out different proving system and see which fit their their need best. Uh we also have a highly modular proving pipeline is shown here. Uh so developer can really just pick and choose which step they want. uh for example if they don't want to kind of have the final onchain verification done they can just drop the the embedding step and they can also mix match and build like different chips uh to essentially build a new VM. Uh but perhaps the most important thing that I want to really highlight about Pico is

our incorporation and the introduction of an app level co-processor architecture. Uh if we think about it every ziki VM here is built with a glue and co-processor architecture. The glue is a vvelina ISA in our case risk VM and the co-processors are a bunch of specialized circuit to accelerate specific things like most of them are pre-ompiles. However, what we found out when integrating building with our partners especially in the uh adoption consumer side of things is that pre-ompiles are often not enough to offer the uh bath performance that is needed. So to solve this challenge uh Pico is really built with an architecture that can integrate app level co-processors that this co this

kind of application level co-processor can undertake a very large chunk of a common proof computation workload uh you know that is not only just optimized z circuit but also application where system that can organize and orchestrate these kind of specialized circuit effectively. Uh so we have this kind of thing called zik data co-processor that let you prove existence and computation on historical oning data. So in our benchmark, this kind of single add-on can give you 32 times faster proving time and cut the cost to one/3 to prove things like unis swap trading volume for a user and directly use that in smart contract. Uh so finally I just want to highlight that pico is the fastest zkm uh on CPU uh for various different kind of workload uh without you know any kind of app level uh co-processor magic we

talked about and we're right now working on GPU acceleration uh solution. Uh we're a bit late to the game, but we're catching up really fast and we'll get uh on the East Proof next month when our GPU version is ready. Yay. Next month, uh Eve proofs integration. Uh really looking forward to it. And uh do you think you'll also be the the most performant on GPU given that you're most performant on CPU? uh well you know that that we will see like because I know there are a lot of great teams uh racing on the GPU acceleration things but we we are taking a quite a different approach uh you know uh to uh to GPU acceleration uh so like you know but this is a a red hot topic

right now we're just looking forward to it and will your GPU work be open sourced uh so that part uh you know uh we're still kind of internally discussing Okay. But like I think to to a to a at least to a certain extent that is like we don't we don't you know there are a bunch of like things that uh is like uh you know hard to do but there are a bunch of things you can kind of you know fit into our modular modularity design from a user perspective when they actually mix match different proving pipelines uh they should be able to kind of manipulate the some corresponding part uh for the uh uh for the GPU acceleration as well. Uh so we we are a

big believer of cross stack design that you know even for layer one acceleration and layer one kind of a VM redesign we believe that this is not really just only a z but also kind of a a VM design problem as well and you mentioned multiple backends uh circle starks baby bear cola bear which one have you found is the fastest for ref or revm uh right now it's a stark on cola bear is the fastest one Okay, got it. Okay, thank you Mo. Next up we have Leo from Powder who will be talking about Powder VM.

powdrVM by powdr

Hello. Can you hear me? Yes. Cool. Um, yeah. Hey everyone, I'm Leo from Powder. Um so powdervm is built on top of the powder SDK um which was built with flexibility and modularity in mind and has a multiffront end and multi-backend approach. So in the front end for the ISAs we have risk five released and um we're also working on a um the redacted ISA which should hopefully be better than risk 5 and on the back end uh we use 32 and Halo 2. Um but what actually makes Pyro truly unique is its middleware um with a bunch of very powerful compile time

optimizations. And so we've built the auto pre-ompiles which are automatically synthesized pre-ompiles um in order to basically accelerate um any gas programs that are using any libraries. They are fully automated. They're is agnostic and should be quite suitable for form verification which is um something we want to do for these soon. And we've actually also integrated this module with other ZKVMs not only powder VM and we already see uh three and a half times faster end to end proof times including recursion. Um we're pretty confident we can get this to 5x soon with the goal being 10x for selected complex benchmarks like EVM for example. We also want to use the same

technique to generate formally verified um circuits for existing pre-ompiles like catcha that everyone is interested in that will also hopefully be more performant than the manually written ones. So for the zikvm builder so I guess everyone else here um let me know if you want some optimize um yeah so powder is fully open source uh dual license and it can prove VM blocks but recursion is not ready yet okay thank you Laro um I am curious to learn more about this redacted ISA um in the discussions around um Vitalik's recent blog post around potentially enrolling risk 5 you seem to lean

against uh risk 5 is maybe the proposal that you'd like to put forward the redacted one the redacted ISO um not necessarily um I think there's a lot of space a lot of design space around such an ISA if you want to enshrine one um I do think risk 5 is a great ISA for execution I'm just not convinced about the ISA about that being the best ISA for ZKVMs or in general the thought of enshrining an ISA for Zakavian. Um but yeah, but I think there there's been lots of arguments in favor of like was for example or different um specific things that one could do than

than risk 5 in a in a custom ISA. Um and we see I mean here in the list we have uh different teams working on their own ISAs and of course we have risk five was and potentially others. So I think there's a lot of room for discussion and we'll see a lot of optimizations in that space soon too. Alex Hicks in the chat asks, "I remember the earlier blog post about the automatically synthesized pre-ompiles. Is there more public material now?" Um there's more code. So that's actually the the better outcome, I'd say. Um but yeah, so there it's it's from that blog post. So since then we've just coded more stuff, more

optimizations, more integration with different tooling and yeah this is kind of the result we see now and yeah I guess announcement of announcement we'll probably release some more stuff uh publicly soon and ask what links a front end and a back end in the context of powder. What links? Yeah so he asked imagine risk 5 with a plunky 3 back end. Is it that you can just pick and choose any back end and any front end? Oh, right. Uh, yes, that's the idea. So, you can basically at runtime say I want a plunky 3 proof or two proof or hello 2 proof um for the same ISA. So, they're not connected at all like in a tight manner.

That's the whole goal. And even within the provers, you can also choose the field. So, for Plunky 3, you should be able to use Koala Bear, baby bear, go to locks um and M31. and with two and 31 only, Hilo 2BN only. So, um these are the Yeah, you can you can choose all of these separately. You don't have to they're not connected um in any type way. It's interesting. We're starting to see a theme here where we have uh platforms to for for ZKVMs as opposed to actual ZKVM. So, OpenVM, Powder, uh Pico, I guess all fit. uh even the the 01 VM uh fit that uh that format. Thank you so

much. Yeah, just one comment on that topic. Uh yeah, I wanted to also shout out the the concepts that um OpenVM implemented because it's really cool that you can also um write extensions without having to fork and modify the code at all. I think this is really good for the KVM development. Okay, thank you Leo. Uh next up we have Jeremy from Rest Zero who will present uh our zero VM. Hello. Can you guys hear me? Yes. Let me just share my screen here.

R0 by RISC Zero

All right. Can you see that? Yep. All right. Cool. I just wanted to say hello. Uh we are risk zero. Um I think we were actually I mean we definitely were the first people to do a risk 5 uh ZKVM and it's uh great to see that uh that is starting to become much more of a standard. Um we're also the the first to actually have a type one ZKVM that could actually prove uh an Ethereum block. Uh so we you know we hope to continue to be innovators. We're actually uh soon going to release boundless which will allow full decentralized uh proof generation.

Uh but I think you know largely we're sort of speedr running the performance uh you know in terms of just general ZKVM performance. Um you know we just released V2 a V3 is coming out not too long from now we hope uh to see you know 10x performance in that. Uh, interestingly for V3, we're actually going to support our existing Baby Bear based proof system as well as Binius through some work that we are doing with irreducible. Um, and we're targeting real-time proving by midyear. We're currently already under 30 seconds a block. Uh, and we expect to get to real time even without the improvements from V3. Um, I think the other thing to note

really is that, you know, we are the currently fastest 100% open-source Risk 5 ZKVM. I wanted to point out that our GPU acceleration for our proof system is fully open source. Uh in fact all of our projects are fully open source and I think that you know as we start looking toward using these things for things like enshrining Ethereum this is going to be critical you know we're very bullish on on that. Um and I think you know one thing to note is we are seeing this massive cost reduction. We've been seeing this uh continuously we are trying to push it. We know a lot of our other folks in the industry around ZKVMs are pushing it. It's great to see so many people working on this problem. Um, you know, I think in addition to all the

improvements on the ZKVM, we also really believe that the token incentivized markets will in fact uh improve these performance as well. Um, as well as you know continuously working on pre-ompiles. I think that's been a common theme we've seen here as well. And I think also one thing to note is the whole point of a ZKVM is security. And I think it's very important to be extremely serious about security. We always are. Um we in fact already have uh formally verified the sound the determinism of our circuits using picus with uh the help of uh you know some partners and we're also currently working on full formal verification as well. So uh there you go.

Perfect. Thank you, Jeremy. Um, one question in the chat which has already been answered, but I think it's worth re-emphasizing is is the whole code open source or just the binaries? All of the code. All of the code 100% open source. All of our CUDA kernels the there's nothing closed source. The compiler is open source there. Like uh I guess the exception is there's a couple of pieces of boundless that are not fully open sourced yet. those are uh although most of that is also open sourced as well but the entire ZKVM all the acceleration is all open source amazing and one of the things that we're going to see soon on if proofs is you know large clusters of let's say a 100 GPUs is all of the orchestration logic for these large clusters also open

source um much of the orchestration logic is we actually currently have two different orchestration mechanisms one is bento which is going to be the mechanism used in um bottomless which is open source Then there's we have our internal bonsai program which uh we do not have that currently open source but I think we're probably going to move to the open source orchestration as well longterm. So uh yes amazing thank you so much. Uh any questions for Jeremy? I mean, I think you guys have made a a public commitment on Twitter to have real time proving uh by June, I believe. So, yeah, congrats on making

such a bold claim and looking forward to uh the end of uh end of June. Yeah, our hope is to get there even sooner, but yeah, we're we're going to push really hard because we think that this is a huge uh you know, we we we're we've been first on a number of things and we hope to continue to be first on things. So, we we're working on it. Awesome. Thank you, Jeremy. Next up, uh we have Uma from Succinct who will talk about SP1. Uma, you might be muted. Okay. Can you guys hear me? Yes.

SP1 by Succinct

Perfect. Um so, SP1, what it is is a risk 532 IM ZKVM. Uh it has extensive pre-ompiles. So catch Shaw SECP 256K1 BLS 12381 I think almost all Ethereum pre-ompiles and some extra as well. It's open source MIT Apache 2 license for the verifier and the CPU prover. The GPU provert isn't open source but we publish a binary so that you can run it locally and many people have. Um we have this N10 GPU prover and we also have a multi-node GPU prover which is really critical for reducing latency and in all it's the fastest ZKVM

on proving Ethereum blocks and actually on ETH proofs um you can go to the ETH proofs website and uh there's succinct snarkify and zate cloud and I believe they are all running um the SP1 prover uh so and you can see succinct uh is the fastest prover out there, but they're all using SP1 behind the scenes. So, it's integrated on ETH proofs, and I think to my knowledge, it's the only current ZKVM integrated on ETH proofs. Um, in terms of security, we have a lot of audits from a bunch of really high quality teams like Veradise, Zelic, Kos, and then we also have a formal verification roadmap that's actually very active and ongoing right

now with Nethermind and also Veradise. uh we have a lot of people using it um like for real use cases securing real TVL so some bridging use cases with Celestian avail uh rollup that's been running uh for the past four five months Tao's using it polygon is using it on testnet mantle is using it on testnet and a bunch of other use cases so rollups e proofs and bridges are really big consumers right And then on real time proving, um, we're actually pretty close already with SP1 Turbo, which is our latest release. So, um, you can see on a block with 15

million gas, it's like 23 seconds. So, only a factor of two off from that 12 seconds. For 30 million gas, it's around 30 seconds. So, again, only a factor of, you know, three or so off. Um and yeah, we hope to have real-time proving soon as soon as possible and there's been a lot of exciting progress uh that we will be sharing uh around that soon. Okay, thank you Uma. So if I understood correctly, the GPU approver only the binaries are made public. What about the multi-node GPU prover? Are the binaries also available?

Um, no, that code is currently not available because it's not really in a state that is open source ready, but we plan on open sourcing a multi-node implementation uh as soon as that's possible. Okay, very exciting. Um yeah, I do want to give a shout out to the second ZKVM that has integrated on e proofs which is uh zk zkips uh from from zk zkm. Um but yeah we are definitely seeing a lot of adoption at least on e proofs uh for the sp1 uh zkm.

So congrats congrats for that. Any questions? Uh question, what was the motivation to go with a customized uh risk 532 IM is for SP1? Um I think we decided to do risk 532 because of you know all the other reasons people choose it. Uh it's Rust compatible, good tooling, etc. Uh I'm not sure what customized in this case means I it it is a standard ISA. We don't customize our the compiler or anything like that. It just has a lot of pre-ompiles but that is not at the ISA

level. Okay, perfect. Yeah, if the person who has the question would like to clarify the word customized, uh we can take that to the chat. Lev asks uh do you plan to drop requirements of trusted prover for your client soon and what timeline do you have for formal verification? What um left? Do you want to just ask the question? Uh where well I already asked it. Okay, but we don't understand it. What do you mean by a trusted prover?

Uh well that's uh when only like your client can provide the proof which is the case for uh the uh like uh overwhelming majority of customers of SP1. Do you mean client side proving? No, I mean the cl the client uh uh well uh well not that's typ typically the uh service that provides the proof. Uh yeah so just to clarify the prover is not trusted. Um so the verifier is open source people run the provers locally as

well. So there's no trust assumptions on the provers in terms of the multi-node prover which is maybe what you were asking about. Um we plan on having that being available as an option for our customers um through like our prover network or something like that uh in the future when like the code is in a spot where it's ready to be open sourced. Perfect. Thank you. Thank you, Uma. Next up, we have Mami from Lita who will talk about Valida.

And congrats to the 113 people who are still here 1 hour and a half in. Hi. Uh I just have um sharing issues at the moment, so I'll just do it without uh sharing any screen. Um anyway, so uh I'm Mommy. I work at LITA on uh the valid KVM. So the valid KVM is made of two part the valid ISA uh and the valida prover. So uh as far as I know the valida prover is the first plunky freebased prover and well the valida ISA is um I guess the most mature uh custom ISA for ZK uh today but I like that

Valida by Lita

reducible and powder and well also Cairo are exploring custom ISAs. So one thing to note is that optimizations on the ISA side are multiplicative with improvements on the prover side. So I think people shouldn't sleep on uh compiler tech and uh on that front we are happy to say that we stabilize the compiler tool chain and the ISA of Valida and we will have uh a paper released next week on IAC that formally specify uh our ISA and that people can uh target as well. uh and or compiler is available uh uh in regular releases. So we support

today uh fully free languages. Uh we support C, we support Rust, we support WAM. So you can prove any of those. We have Go programs uh pending. The compilation works but we need more tests to ensure that we don't have bugs. Uh we can support new languages for example uh C++ we only need to implement the standard library in Valida. we can support name or zig any uh language with a very small runtime. Um I guess the cave hat is that uh to prove full e block we are pending recursion. Uh I will frontr run just in question about GPU acceleration uh is being explored. Uh but we're compiler

team. So instead of writing CUDA uh code uh by hand we have um a CUDA and uh PTX. So the Nvidia assembly code generator code generator written in NIM to avoid having to write CUDA code by hand and this can be adapted we have our own um I guess a uh to represent uh GPU op codes so that we can uh generate code for AMD Mac or Vulcan GPU um I say being explored because uh for now it's just proof of concept to see what direction to pick but it's promising has for micropatric code is 5x faster than icicle uh handcoded implementation for

example. Thank you VM. Uh yeah super exciting that you guys are going with a custom ISA. Um sorry to ask this question when open source. Uh it's a a good question. At least we want to finish uh recussion uh to have something um well uh complete to show. Uh it's worth noting that the previous valida um is open source uh and it's resemble a lot with the current one. Uh but yeah, it's uh it's uh it matters uh on the business side how we choose to uh

monetize and makes the company um um how do you say it? Uh like uh profitable. Yeah, sustainable. Sustainable. Got it. Uh Gotam asks any preliminary PF results on type one EVM block proving with Valida? Uh as I said uh on small blocks we are really really fast. Uh but uh well production uh especially with EIP4844 blocks are super large. So um we cannot fit them uh into what we have without uh continuations and recursion.

Got it. Thank you. Um any more questions? If not, we'll move to the next speaker. We're almost done. Uh, only four to Um, okay. Thank you, Mami. Next up, we have uh Wyatt from ICME who will discuss uh ZK engine. All right, I need to turn on my Zoom thing real quick. Sorry about that. I might have to stop and restart. Does uh William have my deck actually?

zkEngine by NovaNet

Yeah. Yeah, I have it. You want me to pull up one page? Thanks. Mhm. Cool. I'm just going to start anyway. Uh what is Novet? Nova is an NIVC folding based pro network. Um so we've been working on folding for quite a while from nova to supernova uh to neutron nova and now um we've basically built a zkVM on top of this works off of wom at the beginning has two different types of use cases. One is top down which is parallelization of large proving tasks that we break up among many machines and other is actually bottom up proving where you take a bunch of privacy proofs and kind of aggregate them together efficiently and then post them on chain.

Um why is folding important? One is for decentralization you need to have uh many different types of machines being able to join the network. I mean with folding we actually choose the step size small for small machines or very large for very large machines. So we can get both uh really small machines to join and also very very powerful machines to join and uh kind of go with this essential that way. It has really good liab midway and anyone can verify. It's called incremental verifiable computation. I think it's just really cool. Um with a more monolithic type proving system if you die the proving scheme dies midway you have to restart from the beginning. So we do like the livveness of folding. Um yeah so with efficient continuations folding actually has the best uh form of uh sorry the best overhead for kind of these

continuations in the literature. So we actually fold multiple instances into one thing uh and also only just commit to the witness while doing that. Uh the PSC team actually worked on a onchain verifier and we continued that work and now we can actually post this stuff on chain with 150,000 gas. One other really cool note is that it's private by default. Most eqams are not privacy preserving whatsoever. There's a trick in the hyper paper that's been updated recently. You actually just fold one time and you get this really cool uh way to have basically pure zk. Um, also and a very important fact about having an NIVC or non incremental verifiable computation network is that you have pay per op code type proving and this is important because you can actually have specialized provers join. So one earlier one they're looking for is Jolt can

actually join. There's two ways Jolt can get on to uh continuations. Now one is with this real time uh folding and the other is with a uh the paper that Justin mentioned earlier. So with folding we actually break up jolt proofs and have it run machines for continuations. So we can actually have these specialized provers also join our network which I think is just really cool. Yeah, that's all amazing. Uh thank you Wyatt. Um so right now presumably you're doing folding with elliptic curves but there's a bunch of new literature around folding with with hashbased schemes. Is that something that you're investigating? I mean you did mention Justin's latest paper. Yeah, I don't think we're going to go in the hashb direction right now.

We actually coming up on Nebula next step which should be neutron nova that gives us a 10x speed up. So we're going to do a benchmark real quick and then we're going to see what happens. We expect to be a little bit slower than the starch type systems. It's not specialized yet neutronova should have uh the speed up from there but then from that we can go to neo which is actually lattice based and we think that's more promising for a few different reasons uh going into the future. Uh so we have no plans actually to go into starkish or fry type systems uh in the near term. Okay, any questions for Wyatt? Just raise your hand or ask it in the chat. Um, all fully open source, right, Wyatt? The DK engine at the bottom there, there's a link. It's been open

source for quite a while. You can try it. Actually works in browsers. We are doing web GPU. Um, and that should be out relatively soon as well. Perfect. Okay. Next up, uh, we have Jordi from Hermes who will talk about Zisk. Well, hello. Um, can you see the screen? Yes. Hello. Okay, perfect. Uh, well, uh, this is, uh, very much risk five architecture. Maybe the main difference with other risk 5, uh, architecture. Uh, and the other important thing is that this optimates for latency from the first day.

ZisK by Hermez

Actually, what we are trying to do, the main goal is to uh, achieve the highest latency here. uh of course when you're optimizing latency you're also optimizing cost but uh the main goal is to optim optimize latency so the goal is to to to prove in real time by by design this is what we are targeting right now it's a 128 security I think this is important to mention this is a standard in the in the I mean in the crypto in the space everywhere and it's as I said it's a decentralized I mean it's distributed and it's a paral distributed I mean it's this the full system the full prover from the execution until the recursion and everything is built to be distributed in many in many machines so that there is many machines that are

building the proof here. I'm very excited on this new version of FP proofs uh um having the clusters and and and because I think this is the the way to go. Um not to mention that's fully open source. Everything including the GPU proving so all the code that we are doing is open source by mean it's by principles and uh everything is based uh so all the project is based in the polygon her is where the polygon ckm is running. who have experience uh running for the last uh uh two years and is using PL2 is tslong I mean all the all the tool set that's uh quite proofed in there we I mean we have most of the per compilers we're still working in uh mainly in the

pings one and there are some of them that are finished as I mentioned we are targeting real time proving I hope that very soon we can uh share and connect to the if proof and me as a side note what makes this one of the important thing is this parameter of um 0.15 seconds for aggregation actually we can lower that a little bit but this is what what allows that the all the aggregation system is only um one two seconds and and all the rest can be paralyzed very much in many machines I mean that's the main detail of the prover u of course a lot of work to do in the front I mean pre-o compiles audits documentation but uh yeah very excited we are pushing hard on this

project. I think it's very important for the space. Thank you, Jordi. Uh George Kadinakis from the EF ask, what is the secret to so fast 2:1 recursion? 0.15 seconds seems very fast. Yeah, we are mainly using the techniques that are built in plunk. Uh plunky 2 is already very fast and it's a full implementation, but we are taking that and also this in GPU build. So it's actually we are building all this in the single GPU and I mean there is a lot of uh knowledge I mean circum so the main circuit is built in circum siron has a model for paralyzing I'm the author of circum so this has all the paralization so what's the window

computation of the circuit is really fast and then uh this circuit has um some uh custom gates um for the recussion so this is what makes this circuit small and really really fast and that's the the the the the big trick uh here for aggregating circuits. And Jordi, we had a call recently where uh you discussed this really cool technique to collapse the the depth of a of a tree of of of segments down from log logarithmic to something lower where you can basically prove every segment independently and then because of the homorphisms of of commitments basically uh do it in any

order you want. Can you talk about that a bit? Yeah, the the desk here we're using an accumulator for uh an accumulator for uh computing the uh mean for computing the the the challenges. So that means that uh we can build the proofs in parallel and then this accumulator because it's an elliptic curve one you can add them uh no matter what's the order. So you can build the proofs at the at the order I mean no matter how you uh aggregate the proofs you are going to get the same challenges. So you can uh uh proof uh uh so you don't have the dependency of uh having to wait on the other. This has another advantages is that the the memory requirements that in the first Polygon Hermes prover was uh I mean you

you require a huge amount of memory in the current version you don't need uh I mean you you you need much much much less memory maybe 64 gigabytes or even less. So it's it's very limited the memory that you need for building the proof. That's together with some other tricks. But that's very much the idea. Very cool. And I love the fact that you kind of built this from day one from scratch with uh latency in mind uh which is perfect for the Athereum use case. Uh Jeremy from Reszero says uh we are at 210 milliseconds for 2:1 recursion. So pretty pretty close uh to 150 milliseconds. Uh yeah, that's that's a good number. Yeah, it took a lot of we

had to build a lot of custom circuits though as well and that is also with GPU acceleration. I think that but I do I I agree that this is like the next frontier in terms of as it's really the limiting factor for parallelism. up. Yeah. Here I mean last numbers I think we can go low to 100 milliseconds but that's that's very much the number. I mean going lower than that probably maybe with hardware uh acceleration you can uh hit that part but that yeah that's that's a good number. Yeah, I mean slightly different topic, but for the beam chain we're looking to do aggregation of postquantum signatures and here we we care very much about the performance of recursive aggregation of

signatures which is basically just just recursion and here we're looking to really embrace where which has these smaller proof faster to verify proofs uh and actually just yesterday I think there was like a mini breakthrough where the cost of the wear verifier was reduced quite significantly. Uh, so getting down to 64 milliseconds, I wouldn't rule it out even maybe 32 milliseconds. Um, in our space everything moves very fast. Jordi, thank you so much uh for the exciting presentation. Uh, next up uh we have Stefan from ZKM who will present ZK Mips. Uh Stefan, we can't hear you. You

zkMIPS by ZKM

might be muted. Hello. Can you hear me? Yes. Okay. Okay. Can you see my slides right? Yep. Okay. Yeah. I'm Stefan from the ZKM and ZKM is uh the first industry uh I'm in the industry first ZKVM that supporting the MEIPS uh 32 and it's open sourced. So first uh I think we uh should mention uh mention the difference between the MIPS and other general purpose uh instruction sets. Uh I think the most important uh um point is uh the MEIPS is very very uh consistent which means that different uh you know the hardware

vendor or manufacturers they follow up the same uh instruction set for some special you know um uh watches versions. And uh another um feature is uh we have some you know um composites on on this opt which can makes the you know the trace of the uh uh the programs execution more shorter. So it's uh basically can minimize the you know the the chips areas uh to prove and um uh currently we have um uh the MEIPS uh 0.3 is proving is proof now and we uh for the uh the one uh the MIPS uh

1.0 Z is uh will be live uh in May uh with a six to 20 uh 20 times increase in the performance on the CPU and uh it's also we are launched for the proof uh in next month and uh we uh the performance may uh the performance improvements uh probably comes from uh uh yeah most comes from the uh leap compar set memory check and the plant three. Yeah, we uh switch from the you know plant two uh to plant three right now with the um corner field and the GPU acceleration uh for uh 1.0 zero came

through uh probably in two week in two weeks and uh yeah so uh for us we expect that the real time proving comes in by Q3 uh yeah basically that's that's all okay wow very exciting uh six to 20x increase in a couple weeks sounds amazing uh and is that right that been not using a GPU right now. Uh uh yeah, for 1.0 we don't use a GPU, but for the 0.3 we uh because it's 8.2.

Yeah, it's only GPU. Okay, got it. So in Q3, I guess you'll have both uh version 1.0 and the GPU acceleration. Uh yeah the GPU acceleration uh basically we cames out in maybe in two weeks I think and we estimate that that's the you know the end to end time for the uh block uh land block maybe it's about 23 uh uh yeah 20 seconds to to prove.

Got it. And um is all of your GPU acceleration work open source? Um uh it's uh probably not not open source. Okay, got it. I'm not seeing any questions in chat. So yeah, thanks again. And uh we have our final speaker. Uh congratulations to everyone who made it uh so far. So that's going to be Sinka from uh Delphinus who will talk about ZK WASM. Uh hi this is Sinka. Uh we have a CKVM that supports web assembly. It is initially implemented in Halo 2 as a

zkWASM by Delphinus

reference implementation three years ago and it runs pretty slow in CPU at that time and then in Halo 2 GPU at about 20 seconds for one minute instructions and then we released uh another CT was improver which is optimizer version about 7 seconds for 1 mill instructions on web assembly and the main blockers of the performance because the Web Assembly has about 140 junctions uh 64-bit memory with an aligned feature and some kind of frame feature for the web assembly which is a bit complicated. So it's about 7 3 seconds for batching uh of the

continuation. And we have a PhD working in Jaoong University actually porting that to porting the reference circuit to hyperplunk which actually have a fairly good performance in CPU but we do not have a continuation for that and um there's another porting of the reference circuit to cork which is interactive sorry to interrupt very quick question do you have a slide or do you no I do not have a slide no slide okay gohead Yeah. Okay. And that um reference implementation is also ported to CO which is a interactive approver by CITIC. Uh they do the formal verification there. They somehow open

source the the cork version circuit but not approved. they have submitted a paper um to PLDI but unfortunately get rejected I think uh last of few months and we are trying to um maybe derive the circuit from the cork version instead of the hello to version very soon um regarding the real time proving we we don't think we can make that because currently it's 76 for woman instructions is a bit slow I mean in the market thanks Yeah, that's that's all all on my side.

Okay, thank you so much. Straightforward. Yeah, thank you. Uh Jeremy says, "Was just a more complex ISA to implement. Spec is significantly larger and has significantly more up codes." Um would you agree with that statement? Yeah. Yeah. It's it's it's a it's a monster. Uh it's a monster. Okay. Yeah. Yeah. I I would get stuck by the frame um semantics for a while. I think two years ago. It's it's a it's a very weird by code and the circuit is somehow managed to formally verify the

circuit in one and a half year which is huge effort. Yeah. I don't know if Leo is still in the chat, but I think he was also advocating for for WAM and um still here. WAM sounds good. Okay. And do do you agree with the statement that was a is a monster? Um it depends. I don't know. Um it's definitely bigger than Risk 5. I guess that's why everyone is doing risk 5, but I think it's also like it's kind of quote unquote just work that once it's finalized, I think it has a potential to be more performing. Um, but it has a it

has a feature that you can memory read across the 32bit wise uh memory chunk, right? It it almost doubles the memory. So the usual memory semantic not works smelling actually hurts the performance. We have to coding two different group of memory circuits. One with the alignment check one does not have the misalignment. So it's it's it's a bit ugly. I mean I circuit is very ugly. So that's why we we somehow would like to port that to cork.

Got it. And and Leo, are you intending to implement WASM in powder? Um some version of it. Yes. Got it. Which might be redacted. No. So the thing is with was I think I mean Yeah. So S was was right that like if you just take WASM as this, it's a lot of work to do everything. Um, but we do believe that you can kind of massage it a little bit with couple or more than a couple compiler passes and some design decisions here and there to um to make it more suitable for for ZVMs.

Got it. Well, um, ladies and gentlemen, we've reached the end of the call. Uh, thank you so much for making it so far. Um we will have e proofs call number two be dedicated to the provers uh and hopefully by then we'll have you know one or several teams uh that will have already reached realtime proving. See you then and uh yeah godspeed. Thank you. Bye. Thank you. Cheers. Thank you. Bye.