Ethproofs Call #4: Enshrine RISC-V?

Transcript

Welcome & Song

[Music] Welcome everyone. It's 400 p.m. Uh we're going to wait until the song finishes. Um we already have 62 people connected. We'll get started in a couple minutes. >> Risk or ruin. We are the keepers of up codes.

Architects of the eternal machine forest fight the pure tongue covenants crystalline. Why translate abractions? Why veil the truth in bite? Let the base layer brea in silicon. Let the cosmos ignite for stone tablets written in silicon veins are ruin

[Applause] the covenant sealed in ether So, the name of the song is Risk or Ruin. That's one of the questions in the chat. I will share a link to the songs. >> Thank you, Josh. >> Actually, we now have a a new link just from a minute ago. It's actually a cleaner URL.

The future is unknowable and try to welcome everyone. Uh we're going to get started in about 30 seconds. We have 108 people online. through it. A brittle throne for the unborn. >> Okay, perfect. Maybe we can stop here.

Will >> Okay, welcome everyone to Eve Proof's uh call number four. The topic of today's call is risk five and whether or not we should uh enshrine it at Ethereum layer 1. I have some quick slides and then we'll get started uh with the with the presentations. So as usual, if you're watching on YouTube, uh you are welcome to join the Telegram group eveofs community. And if you enjoyed the music, uh, we now have the beginnings of an album from Connor with three songs related to snarks and ephroofs.

Intro Presentation by Justin

Okay, I just want to zoom out a little bit because uh, a few weeks ago, this blog post came out on the Ethereum Foundation blog titled Lean Ethereum. And uh leanthereum in some sense is a even more ambitious project than uh what was announced at um at uh Defcon last year with with the beam chain which has since been rebranded to to lean consensus. It has two other components to it. The first one is lean execution which is what ETH proofs is all about and risk 5 is a a big piece of the the story of of lean execution and also lean data. And an easy way to remember the three layers is that it's C, D, and E for consensus data execution.

Now, one of the things that is motivating uh today's uh topic is the fact that risk 5 is truly truly dominating for the ZKVMs that are capable of proving mainet uh Ethereum blocks. We now have 10 different teams uh and ZKVMs that can do this and nine of out of this 10 are are risk five and it doesn't include other ZKVMs like like Jolts and others that uh are not yet capable of of proving mainet blocks. Today we have an exciting lineup of speakers. We have two quick updates from two different uh ZKVMs uh OpenVM and and Cino. And now we're going to have um

seven different presentations uh on on risk 5 uh trying to cover the same topic across many different angles. Now um so far we've had three EF proof calls. Um one was on introducing the ZKVM teams. The second one was on real-time proving the third one on Gigas L1. Today is risk 5 of course and the the next call this is a a new addition to the to the schedule is on native rollup. So on Friday September 26 we're going to have Luca Dono present and actually just off the press just a few

minutes ago Luca shared this link publicly nativeaps.ltb.com lb.com. He's written a native Rollups book. He's also um writing an EIP which is very exciting. And overall, Luca is doing a fantastic job championing native rollups. And then the three next calls or I guess the the four next calls are uh one dedicated to the proximity prize which I'll be talking about shortly. then the risk fives alternatives and and formal verification all very important topics.

One thing that I've done is that I I've pushed back the the the presentations on risk five alternatives just because I think it's good to give uh these alternatives a bit more time to mature um so that they can be uh presented in the the best light possible. Uh, one quick update is that uh, a couple days ago we've had our first uh, Eve proofs podcast episode uh, released on on on the on the ZK podcast. It's episode 373 with hosts uh, Anna and and Nico who are fantastic hosts.

I also wanted to share a few updates on e proofs that Farah has been working on. The first one is in browser verification for multiple ZKVMs. And hopefully we'll have almost all of the ZKVMs be verifiable in the browser shortly. And we also have a brand new just a few days ago um status uh page which basically highlights um whenever there's some um proofs that are missing for for some of the blocks and the and the ZKVMs. And another quick update is that we are going to have uh an Eve proof day that Will is organizing. It's going to be in Argentina on November 22nd. And we we

only have 150 seats. So, um I think we're going to curate the event. It's going to be an invitation only event. So, uh if you'd like to be considered, please go to this uh link and and register your interest. I think is going to be an extremely high signal uh event and it's also going to be the culmination of of the effort of many different ZKVM teams to be ready with real-time proving uh in time for for dev connect. Now, another thing that I wanted to talk about is uh this new initiative, the proximity prize um that the FM foundation is going to be launching uh soon um maybe in a couple months, maybe

a little bit faster. Uh there's a new website proximityprize.org or and the idea is to try and prove or actually disprove some of the conjectures that the the ZKVM industry is relying on today, especially the hashbased um stocks. Uh there's going to be more information uh shortly. Um but yeah, it's it's the idea is to really try and uh shine light on on the importance of this problem. And we have a a $1 million prize which matches the the Millennium Prize. And you can think of this particular problem as being in some sense the fundamental hashbased snark conjecture that everyone relies on and and it being the the ZK

Millennium Prize uh if you will. And we have uh two fantastic people who are helping out with the the prize as judges, Dan Bonet and and Jakamo. And if you're interested in in helping out with the formation of this prize, maybe reviewing the rules and things like that, then uh do feel free to to uh send us an email proximity prize at ethereum.org. And I also want to give a little bit of of a sneak peek as to what we're thinking in terms of of this proximity price. take this slide with a huge uh grain of salt because it's very much uh under construction. But uh one of the um

things that we're considering doing is basically restricting ourselves to a setting which is very aminable to to being put in practice by by the ZKVMs in our industry and in particular restricting ourselves to so-called read Solomon codes which are basically just polomials um restricting ourselves to what is known as mutually correlated agreement which basically means that you have these uh these words that agree on the same domain. Um you again restricting ourselves to fields that the practitioners are actually using in practice. So large primes and their extensions, things like koala bear and uh discarding things like

binary fields that have extra structure that mean that these conjectures might be slightly different and also restricting ourselves to a domain which is the the roots of unity in order to be uh FFTD friendly. So this is, you know, a lot of information, but we're going to have a dedicated EF proofs call where all of the rules are going to be very precisely formalized uh and announced uh in in in a couple months. And if you want to get involved, for example, with u with additional prizes or if you want to help co-und some of these additional prizes, then do get in touch uh at the at the email address.

Okay, with that said, I will have a quick look at the uh the chat and uh open it up to the the next two speakers to give us some very quick updates. Okay, looks like we don't have any questions, which is great. Also, feel free to just unmute and and speak up. Um, so ye if you're ready, uh, the the floor's yours. Well, just sharing my screen.

OpenVM Update by Yi

Somehow the slideshow is not working. We'll just I only have one slide. So, uh, hey everyone, my name is Ye, um, one of the founders of Axium and here to present some progress on OpenVM. So, today we're announcing that we're about to release OpenVM GPU prover. Um, it's going to be dual licensed under MIT and Apache 2.0 and it will do trace gen and proving fully endto-end on the GPU and support parallelizing over multiple GPUs. Uh, we've also rewritten the execution for OpenVM with an optimized interpreter that runs now at 250 MHz and improving every day. Uh so in terms of some preview benchmarks and we'll follow up with much more extensive ones with

the release uh we've substantially dropped the proving cost for Ethereum mainet transactions now hovering around 0.02 02 cents per transaction and on a single GPU we can prove a example block we've been using throughout the development of openVM in about 80 seconds this is on 1590 GPU and finally on the parallelization we've made quite a bit of progress since our initial releases and now we're roughly in the real-time proving range we'll have some more details to share with our release um so yeah expect that in the next uh one or two weeks and happy to take any questions uh Amazing.

Fantastic to hear that uh in a couple of weeks uh this will be uh ready to use. Is it correct that this is already open source in a branch? >> Um the prover back end is already open source in a branch on our backend repo and then the trace gen we're in process of porting. >> Got it. And when you said parallel proving 8.5 seconds, which is an a fantastic number, um how many GPUs is that with? >> Uh in this particular one, this is for I believe something like 25.

>> 25 GPUs. Okay, very cool. Excellent. Okay, if there's no further questions, thank you so much, E. and we'll uh open it up to sphere from uh scroll. Hello everyone, my name is Stefir. Today I will present updates and road map on behalf of the Cenote team. So compared with the last time we add recursion to our pruning process, we implement circuits for the GTR and base volt verifier using openVM's DSL

Ceno Updates by Sphere

language which accounts for 30% of the total time. Besides we start supporting catch pre-ompile circuit and our ECC circuit is working in progress. Moreover, we start support both baby bear and goldilocks in our implementation. As for the east proofs integration, currently our GPU implementation achieves 1.5 mgahertz and with 3090 a single 3090 GPU and we plan to finish the E2E GPU support in September and we will on board it proofs in October this year.

Thank you. Any questions? >> Amazing. Congratulations on uh being able to prove mainnet blocks and being so close on the uh on the GPU acceleration. >> Thank you. >> Are there any other pre-ompiles that you're working on? Uh I guess what are the blockers towards uh if proof integration other than the GPU acceleration? >> Uh currently we are working uh on ECC and when it is finished we will start working on other pre-ompile circuits.

Okay. And do you know if the GPU code once it's open source will be uh dual licensed as well just like uh the CNO repo? >> Uh currently is not decided yet. Uh yeah. >> Okay. Understood. I'm not seeing any questions in the chat chat. Again, feel free to just raise your hand or unmute yourself. Thank you so much. uh sphere. >> Okay. Uh next up we have Vitalik uh who will be talking about um risk five as a candidate for enshrinement at L1.

RISC-V zkVM by Jeremy

If Vitalik is here. Uh if not um well would you mind uh giving him a heads up? Um yeah, Vitalic doesn't share his email address, so uh he didn't receive the calendar invite, at least in the public calendar invite. Um I guess we can get started with Jeremy then. Um Jeremy um you've been given this honorary slot uh to speak for half an hour uh about uh Risk 5 because you know you and your team pioneered Risk 5 in the context of ZKVMs and uh yeah the the floor is yours to try and give us as much um of a of a of a pitch to to enshrine risk 5 uh within

L1. >> Absolutely that sounds great. Let me just uh see do share here and make sure my slides come up. Uh okay, you guys see that? Let me see if I can do >> Yes. >> Let me see if I can go to the slideshow mode and have it still work. All right, so people that Okay, great. Excellent. All right. Hi, I I am Jeremy uh CEO uh and co-founder of Risk Zero. And uh today I want to kind of walk through you know in part why is it that risk zero chose uh risk 5 right um which we think has been you know a huge advantage um and you know really sort of started the current set of ZKVMs. I wanted to

talk a little bit more about some of the details of risk 5 that may be relevant. Um, and then just, you know, I I think on the pitch for risk 5 for Ethereum, there's a lot of uh open questions, but at least from my perspective, the things that I think recommend sort of risk 5 as a potential for enshrinement. Um, so you know I I wanted to talk a little bit really quickly about sort of the origins of the company as it relates to the choice of risk 5. So we you know um the the the basically the backstory is that myself uh and the other two co-founders um had uh you know a number of years ago built out a company that did a compiler

for machine learning workflows which had gotten purchased by Intel. we were all at Intel and a little bit bored. Um, and one of the things I had been researching for many years had been ZK. Um, and you know with the creation of Starks uh by the sort of uh Ellie Benasan paper um you know which is also sort of where the some of the proximity gaps work that uh is now core to a lot of these things came from. It became clear to me that ZK was at a point where it would be possible to make very efficient ZK proofs and particularly efficient recursion which to my mind meant that it was going to become a big thing. Um, and I spent a lot of time trying to convince uh the co-founders of my previous

company that we should start a new company with ZK. And they continued to be unconvinced. And largely they were unconvinced because of the fact that the way in which you made ZK at the time which was the traditional sort of circuit based technique was just not anything like programming. um and that they just didn't believe that it would become a big industry when it was so unusable. And then at some point, and no one quite remembers exactly when, um or or or who said it other than that it was not me who said it, uh uh this idea arose of what if we built a v instead of making a circuit for the thing we're

trying to achieve, we built a circuit to run a a VM and then we ran normal programs inside that VM. uh and once that idea was sparked uh I think it became very clear that this was going to be the way that things were done. And so the we now then started to go through this process of trying to figure out what we should use as this um you know VM and of course the first question was to whether to build a standard ISA or a custom ISA. Now at the time the custom ISAs seemed like a really smart potential idea in part because the especially at the time when ZK was fairly new performance was absolutely critical and you can get better

performance um with a custom ISA you can make it more native to um you know ZK but one of the things that we knew having started a compiler company is that compilers are hard and getting adoption of new systems is hard um you know I think one thing that's really interesting to note is that the if you just look at say even risk v which is a you know um a standard that has many people interested in it um and have been pushing for quite a long time the compiler work for the risk v support in LM was started in 2016 and it didn't get promoted into stable uh in the LLVM repo until 2019 um which is you know over 3

years um additionally even after it was stable in LVM, it took another couple of years before it actually became supported in an official Rust release. Um, and so one of the things to note is that the if you're building a custom ISA, the road is very long. Um, and the value you get from being able to run existing code with existing compilers is really high. Um and so on the question of whether we were going to uh and more importantly even things like you know um like like go for example doesn't directly support doesn't even directly use LVM. you know, uh if you you not only do you have to you don't just have

to write a compiler once, you often have to modify multiple compilers from multiple languages, work on multiple library supports, right? So having a standard that's already in use is a huge win. We definitely decided we wanted to go with the standardizer despite the you know the performance downsides that existed at the time although many of those have now been addressed enough that it doesn't matter. Um I think the other biggest is the next question of course was what ISA. Um now of course the most two most supported ISAs right now in the world are really the x86 and the ARM um ISAs. Uh but when it comes to when it came to the notion of building a ZKVM uh based on those they're just completely unrealistic to do so. Right.

Um the um Intel's instruction set reference is 4,000 pages long. There are thousands of instructions uh for x86. In fact, actually it's actually hard to count them exactly because there's so many different modes and like the they they change slightly from version to version. And then ARM also despite being more of a risk based system um has grown and extended quite a lot um and is also still very complicated in terms of spec. Um so and those are the most supported ISAS but many there were other ISAS that did have solid support by the existing compilers um and sort of languages at the time like Go and Rust. Um we really sort of considered the the the sort of

top three which was Risk 5 uh Wom um and Mips. Uh now effectively I won't go too much into MIPS. We ended up deciding not to do MYIPS because um it is no longer as much under active development. Um you know it's more of a historical ISA u the there's a number of issues with it with regard to lack of better formal specification and in general it's very similar to risk 5. Risk 5 is actually in some ways like a modern reimagining of myips. um which really left sort of the question of risk 5 uh which you know the 40 there means we have there's 40 instructions in the risk 5 isa versus wom where there's 170 and so one of the

real questions was you know wom versus risk 5 is where we came to as the next sort of decision point and they're very they're interesting because they are built for slightly different cases so wom does the uh you know in terms of building the minimalist uh sort of zkvm Um, Wom does have a disadvantage in that it is somewhat more complex. Um, and whereas risk 5 is a lot simpler. Risk 5 also has the very uh excellent feature especially for ZKVMs that it has doesn't have any floatingoint requirements. Um, but what's interesting is that most of the other differences are really related to the sort of design use case. Um, you know, Wom is largely

designed to be jitted and to be a mechanism for sandboxing. Um, you know, the assumption is that no one's building hardware to run WOM. Uh, whereas Risk 5 is really built to be an actual hardware ISO spec. Uh, you can certainly use it obviously for emulation and jitting. Um, but it's really fundamentally built to be something executable. And actually that that that fact that it is built for being executable um actually lends it much better for a uh ZKVM circuit because circuits in a ZKVM will look a lot like a circuit in the real world. Uh and so you really do want something that's more meant for actual execution rather than sort of for an

intermediate representation for jitter which is which is WOM is more focused on the the register base versus stackbased is also a huge thing. Now one of the things that's that's true about both of them and the reason that Wom was a really serious consideration is that in addition to being quite well supported um both of them have very excellent specifications um that have been quite formalized. So they're very good for things like formal verification um which I think is going to become increasingly important in this industry. Um they both basically have no undefined behavior. There's a technically some minor things with floatingpoint canonicalization in you know wom and you know risk 5 if you look at multi-processor memory but but I think more or less they can be made to

be completely deterministic uh which is a huge win and actually something that lends these ISAs to be used for ZKVMs even above even if we could build x86 uh support uh the the lack of this sort of this sort of formal specification and this determinism thing would have potentially been issues and they both actually have the structure of sort of a sort of base uh you know uh a base ISA and extensions web asm isn't exactly an ISA but you know close enough. Um so generally the short version is the conclusion was that we chose risk 5. Um and I think that there's a lot of evidence that that was the right conclusion. Obviously we've seen um you

know the rest of the industry follow suit uh with uh this sort of use of risk 5. Um we saw that the decision of using a standard was a huge uh piece of leverage that allowed the you know the the initial version of ZETH that was made by uh you know risk zero was able to run you full Ethereum blocks very early even though there had been many projects that have been working on you know EVM specific ZKVMs uh making a ZK EVM using a ZKVM using existing software turned out to be a really excellent design pattern. Um and I think just fundamentally the speed with which the industry was able to move huge new uh

you know sort of workloads into ZK including not only you know full block proving but with you know the work that we've done for the signal for boundless moving the consensus engine of Ethereum into ZK um I think we've seen over and over again that this notion of using an existing standard has been very powerful. Um >> Jeremy we have our first question from the chat. So the question asks could you design a zk friendly ISA uh from which you would compile was or risk 5 down to so it kind of be it would kind of support both WAM and risk 5. Yeah, I mean I actually think that um that that is a you know as we as the industry continues to move forward I do think

that we will end up with this notion which you see in fact in um in ex in real hardware where you have sort of a front end um and then you have sort of this the you know microode right like the x86 for example doesn't actually implement all those instructions directly it's actually run via microode that's much more designed much more efficient and in the case of um in the case of ZKVMs maybe that translation actually happens not in the hardware but you know by an earlier software layer of the stack. Um and so in some ways this notion that the actual circuit needs to be tied so strongly to the ISA uh was a very like convenient starting point but

but I do anticipate eventually we may start to see something like a lower level ISA. But what the nice thing is is that that lower level ISA can now be fairly open. Um and and maybe some cases people target it directly for maximal performance but mostly would not like another example of a of a of a this that happens in practice is currently the um for uh the Nvidia line um the actual underlying ISA changes fairly dramatically between uh the different uh revisions of the Nvidia um the Nvidia uh architectures. However, the PTX is the sort of sort of assembly

language, if you will, of Nvidia. Uh is actually just a it's really a it's really a front-end sort of ISA. Uh people write code against it. Uh but at the very last minute, there's a jitting directly from that into the actual target specific ISA, which gives Nvidia the flexibility to make a lot of changes to how their low system works. Uh and really the PTX is not an actual hardware standard. It's really a it's really a software intermediary. Um and so yeah, I do think that's a likely possibility. >> And Alex Hick says you can compile WOM down to Risk 5 to support both.

>> Yes, exactly. That is also uh one of the things that we uh believe is very likely to happen. I do think in terms of Wom and Risk 5, it's easier to make to do the translation from WOM to risk 5 and Risk 5 is smaller and again I think that's one of the things that really lends it to be the the well but we'll we'll cover that in a bit. So, uh, I wanted to talk just really quickly about some of the details of Risk 5 because I think that like not only was it the best choice available, but honestly the design of Risk 5 is beautifully elegant and it's like just a great like it wasn't that we chose it because it well we did choose it because it was the best thing

available and had there not been an amazing thing but available but still we would have picked the best one. But it actually is almost like perfect for the use case that we had of a super minimalist general purpose machine that is has a has a has a large amount of support. So I mean one thing that to note is that the core instruction set of risk 5 is only 40 40 uh instructions right uh which is and those 40 instructions are very straightforward like this is this table here is the entire ISA uh for the base instruction set and they are almost all trivially understandable by like looking at the little like sort of pseudo code off to the side. Right? We have a bunch of

arithmetic instructions that take two registers and do arithmetic operation on them, put the output into another register. We have the same things but with intermediates or with immediates so that you can actually you know put a constant into your program easily. Um we have memory loading and storing of different sized memory with sign extension or zero extensions. We have the some control flow things, branching jumps and the jump and link register which is ingenious little um mechanism that allows for both efficient uh you know computed jumps but also efficient um sort of stack uh calling and returning mechanisms. Um because it's

interesting to note that risk 5 doesn't actually even have like a call and a return or any stack manipulation uh work at all. the stack is all done sort of in software um because of the sort of clever structure of this jump and link register and then some minor miscellaneous things um LUI and AUIPC are largely to to do large uh immediates. So if you want to load a number that's bigger than sort of the the maximum size for immediates. Um and then you've got the system e call and e bra which is basically how you get into the operating system. And then you have fence for memory ordering and and that's literally the whole the whole instruction set. uh well mostly so uh risk 5 had the way it's structured which is also really convenient both for um

ZKVMs more generally is also this notion of a base and then extensions. So the base is what I just showed you guys. There's really a 32-bit version of the base and a 64-bit version of the base. Um and then on top of that there are extensions. Uh there's the multiply extension which adds multiply and divide which aren't even in the the base. uh which is meant so that you can build extremely tiny hardware for risk 5. Uh you know uh we had have support for the multiply extension because obviously it's uh it's important operation. Uh there's the atomic extension which basically adds atomic memory operations not particularly relevant in singlethreaded sort of execution like we have in the ZKVM but as we move toward more complex models where there is such

a thing as multi-threading in ZKVMs which I think is inevitable as well. Um but then the nice thing is is that the floating point and double support uh of the hardware are in fact in extensions uh which means that they're not required uh which was a big win because building a floatingoint unit in a ZKVM while certainly doable uh is a fairly heavy lift. Um, and then basically there's sort of like a general uh extension that contains all of the above plus some things for um instruction fencing um and these status control registers.

Um and and then there's a there's another variant which is really independent of all these others which is this idea of of a format for compressed instructions which basically just in uh makes it so that you can have both 16 and 32-bit instructions largely so you can fit more instructions in a smaller space. uh it gives you better memory bandwidth for your instruction loading and so on. Um so currently risk R we at risk zero and many of the ZKVMs um are f have focused on the RV32 IM instruction set. Um it was one of the most sort of minimal uh options that we could go with at the time. There's been a movement toward and some of the ZKVMs already are supporting for example the 64-bit

variant. uh there's been a movement uh at an industry level towards standardizing on particular risk 5 uh extension sets and and I think RV 64GC is sort of what many of the langu is sort of the best supported uh variant of risk 5 for many of the languages um that are that are out there. Um I think you know in terms of further paths towards standardization for both ZKVMs and for risk 5 in general um you know we really uh believe that probably most of this will move to RV64GC.

Um, and then additionally, one of the things that is sort of underspecified and varies quite a lot now between ZKVMs, but we believe will eventually is also worthy of standardization is the question of how does the ZKVM talk to the outside world. Um, you know, one of the nice things is that there is a another existing standard out there that we can uh sort of uh use as the north star which is sort of the Linux AI. Um, it's well specified. uh it's incredibly common and uh it with the right additional support within a ZKVM which for example our latest version of the ZKVM has you can actually make a mechanism to do support software and a

separate kernel and user mode um and and actually make the e-all mechanism by which the ZKVM talks to the outside world follow the sort of standard Linux AI. This would allow um if we could move to our V64GC and move to the Linux ABI as sort of the new standard for ZKVMs, we would open up an even wider range of support. Not only would Rust continue to work, but we could actually move toward the uh sort of some of the more upstream Rust uh support for the platform. There would no longer need to be specific ZKVM platform work uh within Rust. you could just use the existing platforms, the existing standard libraries. But additionally, this would open up um an easier time

with the existing C++ work because you would have a working lib C that right out of the box. Um Go uh currently supports RV 64GC um and the Linux AI. um you know Java Zigg actually even interestingly um uh Spider Monkey the JavaScript uh jitting um uh environment in fact will JIT to RV 64GC as well um and so I mean it may open up a path to running JavaScript inside uh ZKVMs which um you know I I mean I'm not sure that that's it uh is something I I I particularly would like to do but I think that there is definitely a lot of a lot of you know and the more we can make it possible for people to bring all of the tooling and

code that they already have into the ZKVM world. Uh I think it'd be is huge. Um so so I think that by moving toward this will we'll actually expand the the the sort of build this power that these systems have which is to bring existing communities and software into these new ecosystems. Um getting there is actually fairly straightforward. The move to 64 bits is really we has not been done mostly because there is some Perf cost. That Perf cost continues to go down as we come up with more clever mechanisms for um only you needing that cost when it's necessary. Um you know it's certainly less than 2x. Um compressed instructions require slightly more complex decoding. And one of the

interesting things is that the support for things like floating point and the rest of everything in G um you know historically has been something that seemed like a fairly large lift. But with this uh ability to have a separate user and kernel mode that we now have and a couple of the other folks in the industry are also moving toward um what it means is that things like floating point can be done by a trap. And this is actually a common um thing that happens in real risk 5 hardware. So um some risk 5 hardware that doesn't support uh floating point uh instructions for example but wants to run software that does have that has been compiled say to like RV64GC

will use this mechanism where they just regard the floatingoint instructions as an illegal instruction and then when the illegal instruction trap happens when it hits the floatingoint instruction uh the the trap handler uh says oh is this actually one of these emulated instructions like a floatingoint instruction and then goes and uh runs a soft float library um and then jumps back into the code. Um that what that does mean is that those other instructions would be lower performance. Uh but what it would mean is that you could use like out of the box lib C or things like that. And you know obviously in the blockchain world not a lot of people are actually using floats heavily but the ability to have them there so that the compilers tool chain can be the standard compiled tool chain. So if

someone does happen to use a floating point for some small portion of the computation, it still works is a high value thing. Um and then I think in terms of further standards beyond sort of the question of the uh this this issue of the Linux AI and RV 64GC. There's some other open questions around how do we handle some of these things in a ZKVM context. Can we standardize more on that? Can we standardize on a mechanism for talking to the host? Can we standardize on some of the cryptographic acceleration support that we want? What's the mechanism for that?

I think the the current thinking is more in the sort of we're going to build a library that has support for these sort of uh cryptographic pre-ompiles and so everyone can implement that library and then they can do whatever craziness behind the scenes they want, but then everyone will have the same interface for oh, if I want to go get a catch done, I know how to do that. um in a way that's cross ZKVM because we fundamentally believe that as the industry we're going to continue to move towards more standards. Um so I think the other thing to really talk about quickly is execution. Um this is actually particularly relevant on the uh Ethereum side. Uh because obviously the use in Ethereum is different than the use in ZKVM.

One of the things that I think is really interesting is that on the execution side you know um people have built uh you know sort of emulators. Um additionally there are like jitting uh emulators like uh you know that exist for risk 5 which are higher performance than most of the emulators that the ZQVM teams have done. Um you know such as um uh my brain is skipping on the name of the emulator but at any rate Oh, sorry about that.

>> But no worries. No worries. Uh QMU. Thank you. That sparked a my brain a little there. Uh so yeah. Um but uh but what's interesting is that we've seen recent work by the ZISK team uh which shows over a gigahertz of execution speed and this is done via ahead of time translation mechanism. Um and then basically uh you can actually create process isolation and sandboxing uh via using the virtual memory mechanism of the of the existing hardware. This allows us to basically translate um you know risk 5 uh code directly to x86 or a similar mechanism could be built uh for ARM uh and get fairly close to native execution speeds for the uh risk 5 code um you know and which is I think really

important for use cases which are not just sort of ZKVMs. One of the interesting things to note is that the mechanism that is used internally um which is a very clever mechanism uh to handle this jump translation problem of how do you do computed jumps and still make it look like you're operating inside the risk 5 even though you've now moved around all the code in during your ahead of time translation. um actually is interesting because it that same mechanism can be used to do cycle accurate gas metering of risk 5 code and to sort of sandbox the number of maximal cycles of execution risk for risk 5. Um and so I think that that work um is also helps sort of lead the way to how one would build sort of um uh the necessary

Ethereum sandboxing for uh for risk 5 um which I think was when that the whole notion came up. one of the sort of open problems that I think was somewhat concerned and concerning. So I just wanted to talk really quickly about risk 5 for Ethereum. I mean obviously a lot of the discussion um up until this point is really around sort of this idea of why is risk 5 the right thing um for sort of ZKVMs and where are things going in the ZKVM world. Um but I think that the notion of using risk 5 as the mechanism for Ethereum does have a lot of uh a lot of legs. Um you know obviously you know it's a bigger question than uh you know I can as a sort of ZKVM company can answer but I do think that the things to well some of

the important things to note is that risk 5 is a very wellsupported standard ISA one of the of not very many and it is by far the most minimal of any major ISA. Um the design is overall really great supports you know um uh a lot of wonderful things like formal verification. Um I think one of the key things that was uh you know is is a is a critical component from the perspective of its use in Ethereum is that it in fact can support high-speed native execution on non-risk 5 platforms via sort of ahead of time translation um and that it can do so in a way that is you

know can be appropriately sandboxed um and that can handle things like you know like cycle accurate gas ing metering and stuff without a significant overhead. Um because you know with this ahead of time translation of jumps you really only need to add metering for every basic block. You can do a number of things to like be very clever on that. Um and then I think finally there the one of the things to note is that when you're look when considering what the sort of mechanism for the um you know light execution layer in Ethereum is the fact that something is well suited to and matches with the ISAs that are heavily in use on ZKVMs is highly advantageous

because you end up with just a lot less translation issues. um you're not uh you can you can know that you're getting the same exact execution without having to do any sort of ahead of time translation or emulation in either direction. Um and you also have a very accurate matching in terms of the gas costs, right? Um and so the notion that your complexity met metrics on the on the you know transaction execution side are matching to the complexity metrics on the um ZKVM side uh is high. You know obviously the the overall question is a much more complicated one. Um but you know from our perspective I do think it makes a

lot of sense. So anyway and that is my presentation. What's up? >> Okay. Wow. Uh, perfect timing. Um, exactly 30 minutes. Uh, there's a few questions from the chat that I'm going to relay. The first one is what do you mean by combining Linux AI with risk 564GC? >> Ah, so the um the the the ISA is really always the is risk uh RV64GC. But when you write a compile a program for that ISA, if the program accesses anything external to that program, it always does so via some um way of

talking to the op. So if you if if you compile for example lib C, you need a way to talk to the file system because the C standard has the notion that there is a file system and it has to be able to have some way to talk to that file system. Um and uh so any non-pure program which many of these uh software systems software tool chains uh much of the C++ tool chain um you know go uh do require that there is something underneath the user space uh code. Um and the question of how do you talk to that something else? Um the Linux API is actually a basically a specification that says oh if you want to do a you

know if you want to do a sleep for one second you know here is the you set these registers and do an e- call. So it's basically uh the a me the the interface between uh for risk 5 specifically how do you talk to the operating system and if you supported the Linux API even if most of the calls were emulated or faked out what it would allow is it would allow a much wider range of software to run. Now in the case of Rust, we get around this because Rust has this notion of no standard um which is a special mode in which you're disallowed from using any sort of uh you know feature that would involve talking to any kind of operating system and the code must be pure and technically you can write pure C++ code or you know um but but but most people don't um and so

and so to get the widest support of languages you want some way to have some theoretical operating system even if it's not actually Linux you can make it look like Linux which then means means that all these things just work out of the box in some sense. >> Perfect. Thank you. A question for me is what about MIP? >> So the the the what we really came to the conclusion of with MIPS is that there's nothing wrong with MIPS. It's actually quite a nice ISA. Um it's really just that it's not quite as as nice as Risk 5. And the one sort of advantage it does have is that the there is a 32bit MIP support for Go. Um and so like one of the reasons we considered it

more seriously was because it would have gotten us go out of the box. Um however there's also RV 64GC support for Go. Um, and so one of the the we we did consider going with MIPS so that Go, which was a fairly common um probably the the language of blockchain at the time, although it's moved more toward Rust over time, um would still allow us to make a 32-bit processor that had support for Go. But on the other hand, for example, Rust has le lesser support for MIPS. Many other platforms don't have as much support for MIPS. Um the MIP standard is no longer sort of uh being actively maintained with anywhere near

the level of effort uh that is uh risk 5 at this point. There's huge consortiums. There's people building modern hardware with risk 5. Uh the um you know the um there's the the the standards are continuing to add new functionality of new extensions for cryptography or vector processing. Um, you know, and I think that also that that standards body itself is a really well-built like just in general lots of I think it's overall a much more active um project. And just to be to be totally frank, the the fundamental core design of Risk 5 is just a little bit better than MIP in

some ways. They uh it is the spiritual uh predecessor uh to MIP. And so it tidies up a number of things that were just kind of strange about MIPS. Um so the answer is MIPS is a fine choice. I think it's just not as good of a choice as risk 5 for a number of reasons. It's why we picked risk 5. Diego who will be speaking shortly is saying in the chat is itself now moving to risk five which I didn't know was the case. So that's something to to look into. Uh Jeremy, we're out of time.

RISC-V L1 by Vitalik

Thank you so much for this fantastic presentation. Um >> thank you. >> There have been three questions which I'm actually going to punt to the next speaker. Um which is who is Vitalik. So uh these questions are um wouldn't it be ideal to have as much diversity uh at the ISA level as we can have? Um if we were to enshrine RIS 5, does this mean we are replacing the EVM? And thirdly, uh, what are the benefits of enshrining risk 5? And so I'll let Vitalik take the floor and answer some of these questions.

>> Okay, thank you Justin. Um, okay, let me uh just for the for for convenience, I think probably share uh hold on the Okay, share but um there we go. Click. Okay. Um, do the Okay, the this is the the magician's article that I wrote uh about uh I guess 4 months ago now. Uh do you guys see it? >> Yes, please zoom in a bit. >> Okay. Um perfect plus. Okay, there we go. So, great. So the thing that uh motivated uh my uh proposal to replace the EVM um originally is basically that if we want

to think um about uh Ethereum's longer term future and particularly trying to scale as much as we can without compromising on decentralization or adding overly burdensome requirements for various types of nodes. Then at some point like we have to basically make sure that for all of the different uh parts of the Ethereum stack, we actually are using the the most efficient thing and that we're not taking ultimately needless 10x or 100x hits in efficiency that that we're basically only taking for uh kind of legacy reasons that had to do with the

fact that we did not know better 10 years ago, Right. And so I had this chart from Succinct and I'm these days I think both Succinct and others have improved their VMs by quite a bit. And so I'm sure the specifics of some of these numbers are uh have rejuggled somewhat. There's this general fact which is that the two largest parts of uh proving an Ethereum block are hashing and VM execution and so over here over here you see that as the block execution column that's EVM execution and then state root computation is

computing the state tree like in order to change the state route then uh you also have uh some of the other tabs um I think it was init I think in block validation involves hashing deserializing the inputs also involves hashing there's validation of reads um like basically those those other few columns they all involve like hashing in the state tree and so for this and then there's like smaller things like recovering senders which is ECDSA and in the long run because of quantum we have to replace that with quantum proof signatures which are likely to be based on hashes as I'm sure Justin has already

told you 20 times. Um then the ac crew logs bloom is uh well that's like bloom filtering and uh that's also inefficient but there's like different paths for solving it. So basically, yeah, the two bottlenecks are the VM and hashing. And so for hashing, that's why we've had the Poseidon challenge uh running for some time and we plan to run it for some time more. And the plan is for Ethereum to switch wholesale to a prover friendly hash function which uh can be maybe Poseidon and potentially there's things like itai and sphinx as possible alternatives but the basic goal

is for it to be both fast enough to execute in the nor execute normally and at the same time be very performance improvers. And for Poseidon, we've just seen incredible numbers. Like you can literally prove over a million Poseidon hashes per second on high-end laptops. And so that from that perspective, we consider the problem sort of solved in theory, but we do need to crypt analyze Poseidon more and then do the hard work of actually switching over the tree, switching over the chain and so on. uh but then for the VM this is uh the other place where there's a huge amount of overhead that's happening right and

currently the biggest reason why the EVM has this overhead is basically that the way that uh probably the majority of these provers work is that they compile an EVM implementation down to risk 5 and then they interpret the risk 5 and so like you actually have one level of uh interpreter overhead there. Like you for any kind of computation that you're doing, you're incurring the inherent overhead in running EVM on top of risk 5 when the clearly optimal thing to do is to just give smart contract developers access to the underlying VM whether that's risk 5 or Cairo or something else

directly, right? And uh there's good reasons to believe that you might get something like 100x speed up for uh if you do that. And uh I think uh the the way that I would uh describe the reasons why this is important are one is once we fix the hash function then uh effectively this block execution part will blow it up to being like 80 to 90% prover time and so it will be by far the largest uh bottleneck to uh inc increasing the gas limit more and uh make making proving more efficient and make and and keeping proving decentralized and and all of these goals. And also I think uh like

pre-ompiles have been horrible for us, right? like pre-ompiles uh we they're very hit or miss in terms of uh what we uh um like what pre-ompiles we make and then do they actually get used and then there is this situation where like the mod exp pre-ompile that uh we introduced 5 years ago it or I think more than five now it ended up being used very little but then it's contributed to like more than half of our pain in terms of near miss consensus failures Right? Like pre-ompiles massively bloat the trusted code base of Ethereum. And if you like ultimately Ethereum is about being secure, right? And so if we want to look

to things for inspiration, the kinds of things that we should be looking for are I think some of these newer projects that try to make deliberately security focused operating systems for example, right? And those those guys they tends to aggressively minimize down the trusted codebase potent all the way down to like single digit thousand uh lines of code right and like those are levels at which even with present day methodologies like we as human beings stand a chance of making implementations that have zero bugs right with something that's like in the hundreds of thousands of lines we don't stand that chance at all and so risk EVM is very complicated the risk risk five is minimal.

Pre-ompiles are very complicated to the point where I'm pretty sure that the implementations of sub pre of individual pre-ompiles alone are more comp complex than than minimal risk 5 interpreters. And so we even just replacing all of our existing pre-ompiles with risk 5 implementations alone is a pretty large simplicity gain. Uh so um and then uh finally I think there's also interesting value in terms of interoperability. Basically it turns out that there's a bunch of application developers that work uh uh like that come from outside of crypto and what

they would really love is a kind of NodeJS type of experience where you basically use the same language to write the onchain code as you do to write the off-chain code. and their offchain code is written in whether rust or other languages that compile easily to risk 5. And so if the EVM compositor is five, then they would be able to write EVM uh or they'll be able to write Ethereum code in those languages and have it run on chain. Right? So that's uh how I would summarize some of the motivating um reasons for this. Um and then uh there's some uh various numbers here in terms of like basically like how it could give efficiency gains over 100x to

switch uh to risk 5. Um in po I think in later posts I gave uh some different ideas for outlines of like what order uh you're supposed to do some switching in uh the switch in right and so the rough idea that I had is basically that step one we would implement uh risk 5 exclusively um by replacing existing pre-ompiles with it um or even potentially only like starting to add a new pre-ompile that is uh a specific function implemented in risk 5. And then so that's step one and then step two is we would make risk 5 available as a

virtual machine language to smart contract developers. And so what that basically means is that like code would be able to have a flag and like we could like finally use the the eof like version bits for this, right? And uh if the code is flagged as being risk 5 code then like the contract has the exact same interface you can call into the contract. The contract can call other contracts. The contract can load uh can read and write storage. You can check balance. Uh but that would then that would be done with sys calls instead of uh with uh with op codes. And so you would be able to freely choose uh whether to use risk 5 or EVM. Then the longer term idea is potentially we could

um like basically create a functionality by which you can write any VM in uh risk 5 code and then the EVM itself kind of gets deenshrined and uh effectively existing EVM contracts continue to exist but they would be processed through this uh onchain logic that implements the EVM through risk 5 and and it would it to the anthereum client itself it just it would just look like a risk 5 um contract. Um actually one other reason why um I think these things are valuable also is that for proving I think we uh have not started this conversation but we will need to soon which is uh

Ethereum I think we are going all in on privacy and for to do privacy in Ethereum we want to be able to zk proof things and in particular zk proof things client side right um so I could give one interesting motivating use case which is uh what I ZK account abstraction. So the idea here is basically right that today like I use railway and I have a bunch of railway nodes, right? But let's say I want to change my keys. In order to change my keys, I would actually have to like go and flip every single railway node separately over into a new one, right?

And uh basically if you have like a lot of state in a lot of different applications or in a lot of different accounts you would have to do a lot of onchain operations. It's a lot of gas and it would actually like there's nonatomicity risk which is like super annoying for software development. And then there's the the fact that like if you do all send those operations at the same time that's like a massive privacy leak because you're revealing a lot about your state, right? And so what you do instead is you say well in in order to spend a note you have to provide a proof that you can make a valid uh let's say yeah either like

account abstraction like signature or ERC um for forget the name like 1153 signature from from your account and then you and like basically you make a ZK K proof that says where inside of your note you have like a hidden you have a commitments to what your account address is and then to spend from it what you have to do is you have to provide a zk proof that you can spend from that you can uh basically sign on behalf of the account based on whatever logic the account has at the time right and uh if h you can do this uh then uh like basically you can change whatever

you want in your primary account and Then that would automatically propagate and that would automatically affect all of your as all of your privacy preserving applications. And it would also mean that you could do things like automatically every privacy protocol would be multisig friendly which would make it much more secure to have large amounts of money in the in anonymity sets for example, right? So in order for these things to be possible, you need clients to actually be executing a VM client side that is their account signing logic, right? This is expensive and uh like this is seem this is unrealistic for the EVM but the risk 5 seems like it's at a tier where it

actually can be realistic or potentially if we want to go even further then like it would have to be some kind of customized uh customized VM for prover friendliness right and so like basically yeah if you have like account verification logic for account abstraction written in VMs that are more minimal than the EVM. It makes it much more viable for a bunch of reasons. So yeah, in a lot of different uh different things there, but I think basically simplification and better abstraction and generalization enabled by much greater efficiency is at the core of uh the reason why I think this is uh going to be valuable.

>> Great. Thank you so much uh Vitalik for this uh comprehensive presentation. Uh one question from the chat is um do ZKVM pre-ompiles have some of the same security issues as ZK sorry EVM pre-ompiles. Um, okay. So in this case we're talking about I mean ZK via sorry I'm trying to understand like what is the thing that you're talking about because like so far I've been talking about replacing pre-ompiles with risk 5 implementations which is kind of a different topic from uh the whole kind of zk like EVM in EVM for native rollup stuff

>> right but assuming we don't significantly reduce the gas cost sorry increase the gas cost for some of these uh pre-ompiles then the ZKVMs are basically forced to implement the logic as a pre-ompile >> which >> oh so to be clear I am arguing we should massively increase the gas cost of some of these pre-ompiles like there like lots of things that should go up by 5 to 10x in there >> right makes sense um we have a question from Sergey do you want to unmute yourself and ask it >> um yep I can do Um my question is um maybe I don't completely understand what you're

talking about but um usually L2s now when they prove the validity they prove the execution of the EVM code within some client. So the question is uh do these numbers include running an overhead of running such a client and whether you know if the this overhead is a big one and if in the future uh we would uh just purely prove the execution of smart contract risk five smart contracts within some clients. Yeah, I think in this case to get the full efficiency is uh you would actually have to like figure out uh a way to make the VM to make the prover directly prove over the VM execution and like not have

literally everything wrapped in a client. So essentially what you would do is uh you would have it uh like you would have the prover walk over the uh EVM computation or the risk 5 VM computation and then when the risk 5 VM does like calls out through any kind of sys call then like that would uh go go to a risk 5 uh like interpreter over some comp some compilation of some other Kev wrote a comment that got five uh up up votes. Um arguments based on proving performance seem premature. Uh Kev, do

you want to expand on this? >> Um yeah, I was just basically saying that we don't currently know what like the optimal like what is the stable uh proving performance numbers at the moment. like we could get to like the end of the year and proven performance has maybe gone up by uh increased by 10x or something and it doesn't really matter at that point if it's like 59% block execution if proving time is so uh cheap. I mean I don't think proving time being too cheap to meter is like anywhere remotely within the range of possibilities for the next 10 years right because uh like if that happens then that gives us uh like that gives us wiggle room to increase the gas limit by

like 3x or 10x which is something we really want a lot of people really want. >> Yeah, I think we should start off with where we want to go the gas limit. I mean I think your argument holds better if it's like we're just going to increase it uh indefinitely. um then you sort of need to start thinking about what are the big bottlenecks to this goal. But if it's like we need 100 million gas then then we have to start looking back to see if like are these bottlenecks actually significant. >> Yeah. I mean so my thought process is definitely like reasoning from from long-term optima right because uh I think my view is that the gas limit should be as high as it can be conditional on us meeting some

decentralization criteria that are like one of which could be approximated by like number of dollars you need to run a real-time prover and it feels like at any level of gas there is like some amount of utility that we gain from 3xing And so like I actually don't even think that the utility of say a 10x or 100x gain in in in proving efficiency really yeah depends that much on like the the absolute number of on how much efficiency there is.

>> Okay. Uh we're out of time. Thank you so much uh Vitalik for the presentation. Um, next up we have five different speakers that are going to give shorter talks. Uh, starting with Alex Hicks who will share a very recent idea on a risk 5 extension which is friendly to for more verification. Oh, Alex, we can't hear you. I think it's the mic problem. Um, I guess Let's go to the next speaker. Um, Sphere um again from the the scroll team working on CNO uh would like to share an

RISC-V registers by Sphere

idea on improving one of the biggest downsides potentially of risk 5 which is uh the expensive registers. So sphere the the the floor is yours to share your idea. and sorry and hello everyone today I want to share about this topic new possibility for register based CKVM in this sharing I want to share some ideas that haven't been used in the products but are very likely to

sorry and are very likely to speed up the ZKVM designed for register based uh ISA. So it could be a good support for race card and in the hardware the cost of register is really much cheaper than the cost of the memory. So the compiler optimizations will try to keep values in the registers and reduce memory operation. here at least several compiler optimizations here related to this.

However, in the decade VM design, proving register operations is usually uh equal to the to proving a memory operation. People will just think of the register table as a small size of the memory table and prove it using the offline memory checking. They will maintain a red trace and a right trace and use a product argument to prove the equality of of them and to support multiple read and write. uh one register operation will correspond to two OMC records and the cost of the offline memory checking will come from both the IOP protocol to prove

the product and also the polinomial commitment to commit all those elements which is expensive. It seems that and this argument will make the compiler optimizations useless. But is this the only way we can do to prove the register operations? To answer this question, let's have a look at the essence of register. So using a register is to connect the values between instructions. For example, if we have an earlier instruction which will write down its result to the register table which will be read by a later instruction. If we assume these two instructions uh as two

gates in a circuit then it is equivalent to connect the wire between these two gates. So a program without branches can be converted into a circuit. And if we have a program with branches according to the knowledge of compiler we can still divide it into several slices without inner branches or basic blocks. Let me give you a toy example. In this example I want to compute the summation of an array and for simplicity I just extract the four loop basic block from it and write down the risk of fire representation. So in this block for the

first two instructions and it they compute the address of the current value and for the later two instructions and they fetch from fetch the value from the address and update the summation varies for the final two instructions and they are to update the counter by converting by converting the register operations into circuit wires. We can draw a circuit for this part of code and the intuition will be we will prove the the circuit instead of proving this slice of program because it will be much cheaper.

To make it more efficient, we will use a generalized version of GKR protocol to prove it. To construct this generalized GKR protocol, we link together several Sum protocols. Originally a summary protocol is to prove the a relation between several input polomials and several output polinomials. But instead of opening the evaluations of the input polinomials by polinomial commitment scheme, we just plug it plug it plug in it to some other output uh to the output of some other track polic. And this process can be interpreted as the GRA graph.

With this tool, we are able to prove our basic block circuit. We start from the output of the whole circuit and which is BB final note. After proving this BB final note, the prover will generate several evaluations uh which will be passed into the outputs of some earlier nodes. For example, the T A R evaluation will be passed to the BB start node and the T sum prime evaluation will be passed to the at node.

As the protocol goes on, we will observe that all the register operations has have to have been converted to um to v connections or to the evaluation transformation. zone. Currently, we have no register operations inside the block and the only remaining register operations we need to handle occur in the BB start node and the BB final nodes because the BB star node is to have back the register values generated before the current based block and the BB final block is to have pass the register values to some basic blocks

that will that to be Right. And the good news is each register operation in the BB start nodes only contributes a single OMC rate b record bracket and similarly each in the BB final nodes only contributes one right bracket. If we assume this basic block will repeat 100 times in our method, we only have four * 100 + 4 * 100 equals 800 OMC records to prove. But previously, we have 2,800 OMC records because we have 14 register operations in this basic block and each

will contribute to two OMC records. So you can see the big gap between our method and the previous method according to dealing with the register operation. Uh so um what I have introduced uh are the basic ideas of our project deno pro. So our uh we are aim to use a generalized Gare protocol to reduce the cost of register operations and we achieve the following two goals. The first is we we guarantee that there are no register operations inside each replace and they are all converted to

the just simple evaluation transformation. And uh the second we only need register operations in the BB starts and BB final node in each basic block and each contribute uh each view contributes one OMC record instead of two. Finally, we will have our final goal. Let registers return to being registers. And for further information or details of the paper, please refer to this e-rint link. Uh that's all. Thank you. Uh any questions about it?

>> Thank you, Sphere. Uh this last sentence, let registers return to being registers actually reminds me of Justin Faylor who has been saying that in his opinion the constraints that we have in in hardware over time are going to manifest themselves uh in in ZKVM constraints. And unfortunately he was not available to to give a talk today but I did invite him to to give this talk on the the analogy between between hardware and ZKVM constraints and I think he would be very pleased by this presentation. Um, one question I have for you is is it fair to say that this is an improvement to the average case uh execution but not necessarily the worst

case execution where an adversary could kind of craft a workload which prevents this optimization. uh I uh uh I think it should uh optimize the worst case um program execution because uh generally for the long program execution it can't be written by human right so you need to use loop to construct a very large execution and if you have loop then you will have basic blocks and if you have basic blocks you can use these techniques to somehow um speed up the register operations.

Yeah, but I I I should admit there are some uh programs that have no basic blocks or with not good uh good structures but um it is written by the human because it has no branches, no basic blocks. Um but it can't be too long. I mean the execution trace uh do you agree with that? Yeah, you me you mentioned that there's these like uh types of workloads which are are not appropriate for this optimization and I guess in the context of a firm L1 someone could just craft these these worst case blocks and uh >> bypass the optimization.

>> Yeah. And um yeah, but I want to but notice that we can we can let the prover um maybe to divide the basic block themselves instead of just use the the same definition in the compiler. For example, if we have a very large basic block which is not good, we can just like uh further segment it to be some smaller sizes. Um yeah I I mean I don't know whether this answer your question but we can but we might have many techniques to deal with that cases. Uh I think um >> thank you. Guom Clare asks in the chat um do you require ahead of time

compilation of your risk five code to adhere to this new format? >> No. Uh uh let me see. So we might need some prep sizing on the pure side but for the verifier site we don't uh I just like I cut for the time I cut down one slice for the verifier so it's like and because the proer needs to figure out like how to segment the the the program and to make it more efficient but for the verif totally it can um recover the whole jar graph just from the program.

So for the verifier, you don't need purpose testing. You just like go through the program and see how the register um how the what's what's the register operations and just recover the GTR circuit and use GRA to prove it? Uh does this answer your question? >> I think so. Thank you. Um and this is like a a closing comment which is that um there's this um kind of new trend to uh have techniques like M3 where instead of having a very rigid execution trace you allow for for things to be much more more fluid and uh this this optimization actually reminds me of of M3 at least in

in flavor which is which is very interesting. Thank you so much sphere for the presentation. >> Yeah, thank you. >> Absolutely. Um, next up, uh, we have Diego, uh, who will be talking about, uh, the perspective of, uh, optimistic, uh, uh, fraud proof games. Um, Diego, the floor's yours. >> Let me share my screen here. >> Is that good?

RISC-V opVM by Diego

>> Yep. Okay. Hello. So, I'm Diego and I'm one of the uh co-founders of Cartezi. I was asked to talk about our L2 risk 5 optimistic virtual machine, but really I it can't be done in 5 minutes and honestly seemed a bit off topic given the the focus on on L1 here. So, maybe another time. Instead, I'll focus on one aspect of RVM uh and of risk 5 actually that is vital to the this world computer view that that is is current in L2 and I think could be useful in the this newer world ledger zeitgeist of of L1 as well and this is the privileged part of risk

5. So this is not okay. Uh so in in its current form, EVM is is an instruction set architecture that has operating system ambitions, right? It stores smart contracts. It accepts uh external requests and routes them, immediates the interaction between smart contracts. It controls their access to private storage, grants, limits, tallies the resources used by them, and even allows them to revert any changes they made to their state. Right? And these are all roles traditionally performed by an operating system.

So operating systems build this kind of functionality on top of more general features of the underlying hardware architecture. So stuff like privilege levels, memory protection, virtual memory, memory map IO, interrupts and traps and all that. And these features actually co-evolved with the operating systems themselves. And not all computer architectures offer them and notably web assembly the EVM user level risk 5 which is what people have been discussing here and other blockchain related VMs do not. So these were designed to run on top of an operating system and not underneath one. Uh in contrast the privilege level risk 5 ISA offers everything the OS needs. is actually covered in a

different document that most people that are focusing on the user level part don't even look at. So the Cortezy machine is our risk 5 emulator that supports this vision of complex applications built from decades of mature battle tested software right what Jeremy was talking about that is difficult to use compilers because they make system calls and they have interdependencies and all that stuff right and this this type of complex software actually is asking for an operating system and because of that we are forced to support the uh risk 5 extensions that are marked in color here. And this is so we can run Linux distributions unmodified inside the the

VM and not on the outside. And I believe most L1 related projects focused only on the blue ones and what the operating system is asking for is the orange ones. Now what if this part of the risk 5 uh privilege ISA was available in L1, right? Could perhaps a large portion of L1 run as risk 5 soft itself? So stuff like what Vitalik was saying, right? Uh he was saying like some pre-ompiles could actually run as risk 5 code inside the VM, but could al other parts of uh the what actually runs now in EVM could it pro possibly be moved inside? Um so one consequence of this is that the VM would

then rarely need to change right so if we can stick a firmware or an operating system inside uh another is that firmware is relatively easy to change and so what fraction of these EIPs that keep coming could be addressed by firmware updates instead of changes to the EVM. Uh so this firmware could be shared between implementations even formally verified. In fact, there is already an operating system that has been verified uh to run on risk 5, right? So the SEL4 uh could this help decentralized and simplified updates to L2s, right? if they could just get the new uh firmware.

So in pictures, what I'm suggesting is that maybe complexity can be moved around and so some of it can be moved to this firmware and that this firmware can be shared across different implementations and this would be easier if the risk 5 EVM this new version you our discussion actually was friendlier to operating systems. Since I'm not crazy, I know this sounds crazy, right? the current EVM design is not does not mapped very well to a risk 5 computer but this is exactly the point right are blockchain applications the way they are because the EVM is the way it is or is it the other way around uh and so if you were to redesign a bit more freely we could perhaps change the

memory model the storage model and the gas model so that it better fit uh existing hardware and normal conventions in in in computer engineering and then they could map reasonably well and I think that somebody should be hacking together a pro prototype for this type of stuff because now is the time to investigate this these types of uh tradeoffs. So we know that a VM like this can be made that satisfies the reproducibility requirements of blockchains because we've built one to support fraud proofs, right? So our emulator does not use just in time compilation but runs at half the speed of KMU which does use just in time compilation and 1/4 of the speed when we are periodically updating the state

hash. So we can do uh fraud proofs, right? Can also track which parts of the state were touched while running the emulator. And this can be sent to a special version of the emulator that was compiled to run on risk zero or even directly on on EVM. And this is used when we're finishing a fraud proof like it has an API that is uh binds to several programming languages can be stopped and started after each instruction cycle can be even run directly from a persistent disk image. So uh I gave a talk about this this emulator for the Ethereum engineering group a year ago, a year and a half. So we have made significant progress since then. So ping me if you need up-to-date information if you want to learn more about it. We also recently published a

paper about a fraud proof algorithm which is more decentralized and faster to settle without compromising on security. So check it out. Uh and thank you for your time and please ask many questions. Thank you, Diego. The first question from Sey of L2B. Uh, do you know if there's some similarities with Polka Dot Jam here? >> I think that if you're I don't know the names of the Polka Dot uh Risk 5 stuff, but if you're talking about their Risk 5 emulator, I think that it does not implement these um these these supervisor or or privilege mode uh extensions, right? So for example when

Jeremy says that you know if you can implement floating point by trapping somewhere when there is a floatingoint instruction and then implementing this trapping mechanism is part of this uh supervisor mode uh extensions right a lot of this stuff is is the other part of the standard and I'm not saying that the EVM should implement the whole shebang right uh but some of these mechanisms that have not been discussed could be really helpful >> one question I have is regarding overhead. So, Carteesi uh is a fraud proof game. You don't have to pay much of a of a cost uh when execution executing the the risk five supervisor.

Can you quantify the overhead of this the supervisor? >> So, so we're not I'm not exactly talking about a a hypervisor or a supervisor. What I'm saying is that uh in risk five and in actually any modern architecture you usually have different in intel they're called rings security rings but in risk 5 they're called like there's the machine mode the supervisor mode and then the user mode and what you guys are discussing is uh the part of the specification that deals only with the user mode specification right but when you want some service from an operating system the operating system itself has to protect itself from other code, right?

That they needs to separate keep these the different programs that are running separate from each other. And all these mechanisms are part of the risk 5 standard. They just happen to be described in a in a different document. So it when we're running code, we only pay the price of swap swapping to a different uh privilege mode when the program that is running actually makes one of these calls, right? when there are no uh calls to the operating system being made, it runs at full speed just like it didn't existed didn't exist.

>> Okay, got it. So there's a fixed cost every time you make a call in and out of your little sandbox. >> It's it's more complicated than a fixed cost. I think that in the case of the EVM, the cost could be made fixed because it would be much simpler than actually running Linux with all that that it has to support. But so the cost involved would be to change the memory mapping, right? Memory mapping is another thing that is described in the supervisor mode, right? But it's what allows you to keep, for example, the address space of one smart contract completely separate from the address space of another smart contract and separate from but you have a TLB which is a cache that is used to access this stuff. And when you change from from user mode to supervisor mode, sometimes you need to shoot down this TB and this

incurs an additional cost. But this could be made deterministic in in the case of of an EVM which is a simpler use case for the technology. Right. >> Understood. Diego. Thank you so much for highlighting this this issue which I think has been to a large extent swept under the rug and uh people needs to come in with eyes wide open. Next up we have uh Alex from the FM foundation who'll be talking about uh risk five for more verification extension idea. >> Yep. So, can you hear me now? Yes. Okay, perfect. Let me share my screen.

RISC-V FV extension by Alex

Okay, so you should be able to see the slides if I'm not mistaken. >> And yeah, as uh Justin said, I just want to say a few quick things about risk 5 and form verification and also as part of that really ML. So, wrist 5 has a lot of nice things. One really nice thing it has is that it has an nice formal specification which is written in a language called sale which is also hosts a number of other specifications for different IS. Uh now as of recently we also have uh a lean back end for sale amongst the other serum improvers like core 4, Isabelle and rock and I have some very positive uh assurance that I'm now completely sure and uh know that we can definitely verify ZKVM risk 5

circuits against the official risk 5 specification extracted to lean uh which is great news for everyone. So >> my presentation is glitching a little bit. I don't know if it's related to >> uh let me just restart it and see if it if I do window maybe it will all right let's try it this way let me know if it glitches >> uh that's better that for now yes thank you >> okay uh but anyway other than you know these lean backends and integration with proof assistance one of the reasons we like risk five is because it has all of this nice tooling including for analysis and form verification.

Um, but customizers obviously exist and customizers have a lot of nice features and obviously Kyra and Valido would be able to argue a number of good points about their customizers. Uh, and I want to make a special shout out here to Cairo on the topic of form verification because they've also done a really really good job of getting formal semantics for their ISA and be able to formally verify um, things about their pre-ompiles and about their respitization according to this. But there's an interesting question which is also to wonder um if there are things about risk five that we like are there things that we can recover um from these cast isolers which are not in the kind of base risk five model um but that we could otherwise implement with IRS and compilers because in between your

code and the ISER obviously what goes on is actually a number of things through compilers and IRS and possibly there are actually nice things to do there as a kind of hybrid approach between custom iss 5 which is to just have compiler tool chain that accommodate features that we'd like. And here I want to give a very special shout out to Powder who they've been doing the auto pre-ompiles which is also fantastic. And they've also been doing this write once memory IR which is essentially a compiler from web assembly to an IR which then has you know infinite registers write once memory and you know things like this which is things that you would normally see in a custom iser. So they're kind of showing that you know in a very practical way because they're also working with OpenVM on this and having an integration in a live CKVM you can

actually play around with compilers and come up with nice things that you would get otherwise from customizers while still keeping risk five or you know something else that's a standard um below that and we've also been thinking about this on our side of DF um and looking at it from the perspective of how could you like this with full verification you know in mind as a kind of first class thing that you would like to support and been thinking about this actually for quite a while but I think between the recent work by powder and some other recent papers in academia which are completely separate from the blockchain world uh they're actually seems like you can do some very concrete things and one of these things is that obviously verifying compilers is very

hard but you have frameworks like ML which offer a fairly nice way to define domain specific dialects which are set up for specific optimization passes or analysis Um and you can lower between them in a kind of standardized way. And having these individual dialects which are very domain specific, you know, set up for very specific optimizations actually means that they're also quite amendable to formal verification or any other kind of analysis tools whether it be SMT based or something else because these DX are actually quite small in scope and so they have fairly simple semantics. uh and having fairly simple semantics just makes your life easier in general. And this is one of the reasons that TLCK which is an ML a set of ML dialects for uh for circuits which was announced

publicly this week by paradise but which has been around for a couple months now. Uh it's based on ML um and because it can also then um interface with this framework in lean which is called lean which is being developed in Cambridge. uh which is essentially you know a framework for interoperability between lean ml to enable verified compilation and verification of compilation of compilers you know in lean for ml dialects I'm going to keep things going quickly because I want to keep bits in in the five minute slots um but I just want to basically say that there are a lot of things going on in the ml world the risk five world the compiler world in general throughout hack academia and industry uh

which is obviously you know well beyond our our fairly small ecosystem and in particular there's a lot of work going on around verification for ML dialects um you'll see the name Tobias Grosser here come up a lot uh because his team do fantastic work and his team were also actually responsible for the sale lean back end that we're using to to get the risky specs in uh in in sales so he's not a complete stranger um and in particular you've got you know this paper here which showed how to get kind of first class verification um for ML dialects by just thinking about verification ahead of time and getting you know good support for SMT tooling and things like this and then essentially a dialect for for SMT.

This paper here uh which was able to verify a lot of things about people who we are hitting in SSA compilers. This actually included um a prototype on the Google homorphic encryption which is also a a family of ML dialects for homorphic encryption that Google uses uh which is better developed and done than LLDK but you know we're looking into essentially similar things and was one motivation for LLCK uh being being built on ML and some more recent paper uh I think this one came out in May this year which looks at an interesting thing which is uh you know can We have custom risk by advisory extensions and that and how do we handle these with compilers

and things like ML and this paper shows a very nice thing which is that you can actually do this the examples in the paper you know separate from our use cases they're looking at you know linear algebra accelerators that you would use for like deep neural networks or something like this but it shows that you can have you know you can have an IR uh that basically handles a customized extension and then obviously produces uh assembly which has much fewer extens uh much fewer instructions and gives you more efficient code and and things like this. But on top of this also because you're working with ML and as I said earlier you have these you know fairly constrained dialects with fairly simple semantics this is actually fairly formish friendly and so I think in the

near future hopefully we will actually have a ML risk five dialect uh which we can show is equivalent to the actual sale model. Um and then it would be very interesting to play around and see you know can we do some dialects that have infinite registers can we have right ones memory can we have um accelerators for different opterations that we would need to implement as risk five extensions which could essentially serve as you know extra cores in a ZKVM or something like this um and this is quite interesting and it it also relates a bit to the design of the ZKVMs and how you handle extensions and I think maybe open VM have a nice modular way of um of dealing with things like this um but just so that I don't go over The main point I want to make is that uh I think

that there's a huge design space to explore in terms of compiler frameworks and you know trying to get features that we want from customizers through IRS and compilers as well as obviously thinking of how do we do this in a way that's quite aable to form verification so that hopefully we can trend towards you know compiler tool chains which are verified or easy to analyze in many ways whilst also getting a lot of the performance benefits that we want to get anyway from our CKVM. Uh that's it. Hopefully the sort you know go goes out there and if anyone is interesting in this I am hiring. Please get in touch if something like this would peique your interest.

>> Thank you so much Alex. Uh and just for context uh Alex is the lead of the snarkification team as well as the lead of the the formal verification effort. He has been given uh about a year ago a a $20 million budget to spend over three years. So if you are interested in this formal verification stuff uh please uh please do reach out to to him and uh any has a question in the chat but uh I'll let you respond it respond to it async. Um we have 15 minutes left before the hour. I want to try and close before the hour. We have two more talks one on hardware and one on fuzzing. Um Milos uh from Ponos the floor is yours to talk about risk 5 hardware.

Thank you, Justin. So, let me share. >> Alex, would you mind u um stopping the screen share? >> Yes, but it doesn't show me as sharing, which is confusing. Uh I'll leave and rejoin and that will fix it. >> Cool. Thanks. >> Sorry. Go ahead, >> Mash. just find it. Okay.

RISC-V hardware by Milos

So, uh our presentation is I'm I'm by the way, I'm Am I? I'm a CTO and co-founder of Bonus Technology and we specialize in uh in uh hardware for acceleration of uh of ZK mainly but we are now looking also into uh and acceleration uh and efforts for the like a full stack uh support of uh of Ethereum of L1 um but also like L2 and everywhere where risk five uh is uh dominant or um um emerging as as a

essentially um VM and uh building around it. So what we are looking into and why specialized risk 5 hardware uh which we called crypto CPU uh well we want to have a dedicated risk five hardware for a full stack support basically both execution and consensus uh layer uh and we want to have uh basically this at a very affordable prices like a 300 starting from a $300 retail price for accelerator card which would uh enhance the decentralization lightness and overall blockchain efficiency and could be used as a direct replacement of existing hardware uh

basically x86 based u uh server cloud nodes uh etc. And key use cases for us are basically uh high-speed L1 execution uh so having like ultraast catch or other pre-ompiles native support and even more importantly uh zk proof generation so basically uh we provide vector cores and so soal special function units and we include like native risk 5 vrace generation uh that should greatly accelerate uh basically ZK progeneration and this should lead to improved efficiency that

should allow uh cheaper uh operational costs and potential uh to raise uh uh block uh uh gas limits. So um uh what is Ethereum vision? So for example to have a native risk 5 execution of contract logic and uh we should be able to do that uh by um being able our scholar course to execute risk 5m traces natively removing interpretation overhead uh better alignment with zk proving we have vector coursees to accelerate zk fry based proof generation and pre-ompiles matching zk workloads directly u

optimized for cryptograph traffic heavy workload. So we have custom instructions in in vector coursees co-processors for modular arithmetic uh for hashes for entity that that drastically cut uh proof generation time we have uh so in order to have like simpler more efficient execution layer we have hardwareization. So we have separate scholar coursees for for example uh um uh transactions uh processing. We have uh vector coursees mainly for uh zk proof generation. We have trace core course for uh uh native trace generation uh for uh zk proofs and

this provides both simplicity and performance in silicon and for the backward comp compatibility. So the scholar course uh they supports like standard 3264 IM isa uh which allows the same VM abstractions and this makes essentially integration smoother. So how is this crypto CPU actually uh built or what are its fundamentals? So I mentioned scholar course. So uh it consists of eight scholar cores that are enhanced with modular arithmetic and hardware pre-ompiles uh for for example for catchark for eops for modular exponentiation uh we have vector cores for vector

coursees uh they're super wide so up to 512 elements and they're also enhanced with modular arithmetic optimized for fields used in zk proofs like goldilocks baby bear koala bear mercen 31 and the co-processors so special function units for uh critical time consuming uh operations like um entity FFTD hash rounds signature verification EC ops etc and on top of that what we are developing at the moment uh uh one or two trace generations so-called streaming course for native light trace generation uh running at the at the full uh full uh clock speed and a snapshot

with a snapshot restore mechanism um so-called like an hardware API uh and yeah we need uh insights for uh for uh currently different uh ZK teams running ZK proving uh uh where this can uh uh speed up uh basically their proof generation uh but in the same time working on kind of universal uh trace generation that could be applied uh also like in in in Ethereum in the in the future uh risk five based VMs. Um and in terms of like uh uh it should have uh high throughputs like 64 plus GB of high throughput memory on card memory and

large onchip cache memory uh that should allow uh like a scratchpad memory uh fast access of uh uh those vector cores uh and basically enable or remove all the bottlenecks and on top of this like a set of compilers which are expanding on the existing uh um risk 5 based compilers uh for easy programmability like in C++ rust etc. Our target performance is to have like a real time Ethereum block proving doable with like u only four accelerator cards with four crypto CPUs each on the card and our target at the moment is to have like a

scholar and vector course with with most or we're having at the moment like scholar and vector course with most functionality running on FPJ and we are targeting to have an ASIC to be out by the end of 2026 and this is like a production level uh level chip that can be directly used. >> Okay. Wow. Uh four cards, each card $300. So, real time proving with $1,200. That's >> Yeah. So, in this case, uh uh those cards will be so so the cards with like a single. So, we have a couple of uh like models for for uh um how how we want to have those cards in the cheaper cheapest version with the least amount of memory and the single crypto CPU.

That would be around $300. the the most performant card with like four crypto CPUs and and uh like 128 GB of of onboard memory would be something like up to $1,200 or $1,500, but this is still like a very very much cheaper to anything like that that that is that is there now. So the the the goal the idea is to significantly reduce the cost of the hardware to run um um L1 nodes and to run ZK proofs to generate ZK proofs. So to basically be able to make uh uh uh help scalability and and make it affordable.

>> Okay, got it. So it's actually 16 crypto CPU >> 16 crypto CPUs. Yes. >> And uh four times 1,500. So $6,000 and presumably from a power usage standpoint is also dramatically lower. So getting within >> from the power usage point it's it's like 100x >> 100x power. Wow. >> Wow. That is massive. Okay. That's more than I expected. I was uh I had about 10x in mind. >> Yeah. Well those those uh individual crypto CPUs are in the ballpark of only 20 watts. So so they they're they're dedicated. They're they're low core despite having being a wide vector course. Uh and the most of the power will be consumed on on accessing the the

memory which is kind of uh at this point is is uh what is unavoidable but still like per crypto CPU offers uh like 10x compared to today's uh uh server CPUs and and probably like 20 30x compared to GPUs. Got it. Milos, thank you so much uh for your presentation and congratulations to the 90 people who've made it through a two-hour call. So, we uh down to our very last presentation uh Valentine from Diligence Security and um I've only learned about this effort just a few days ago, but I was just so impressed uh by the the results that uh yeah, I invited Valentine to to come on

RISC-V fuzzing by Valentin

board and present. Valentine, the floor is yours. >> Hey. Um, so let me just get this started. All right. So, uh, yeah, today I'll talk about our new Argus fuzzer for um, finding Z uh, soundness and completeness uh, issues in ZKVMs. So this is joint work with um two of my collaborators uh Kristoff and Maria from the Technical University of Vienna.

So why does this um matter? Why does fuzzing why is fuzzing important? Um well, as you probably all know, um building ZKVMs is um incredibly hard because there can be a lot of complexity um under the hood. And um soon they will probably be highly critical for um a lot of uh upcoming blockchains uh like the Ethereum uh L1 because um their security and um correctness is going to be crucial to to run them, right? Um and soundness and completeness bugs are really the most important um types of bugs for these systems because they can result in catastrophic financial and

reputational damage. Um so it can affect both users but also um the teams developing these these systems. Um and fuzzing is really like one of the techniques that's been yeah very widely um applied in in industry to catch bugs early and to prevent hackers from actually exploiting them uh in production. And um even in um the Ethereum um protocol infrastructure um uh fuzzing is used heavily um to to make sure uh things things work correctly.

So now um Argus is the the first uh father that um detects both uh soundness and completeness bugs in ZKVMs and we already support uh six different ZKVMs. um and have already found 11 critical bugs in three of them. So we found uh three soundness bugs uh in um well three sus bugs in total. Uh one in Jolt, one in Nexus and one in risk zero. And we also found eight completeness bugs. Uh five of which in Jolt, two in Nexus, and one in risk zero. And we also received some bounties uh for the bugs we found.

And um all of the all of this is kind of built on an earlier uh fuzzer we developed uh called circus. Uh it's open source by now. Um so this was targeting essentially what we call uh circuit processing pipelines. Um basically these were uh the infrastructure that powers tools like circum or noir. And we ran this fuzzer on four different um uh four different of these DLS essentially uh and found uh 20 critical sounds and completeness bugs. Um I gave a a talk uh at Defcon uh last year about uh this work and we also have a research paper

that will be presented at CCS 25 which is one of the top um venues in um security. Oh okay. Um yeah, so now I'd like to give just a short um overview of what happens sort of under the hood in the fuzzer. Um and the first the first thing that the fuzzer does um is to generate um programs. In this case, it generates Rust programs, but essentially the the Z games we're currently targeting, they're all um uh risk 5 based. So in in our case we just compile to risk 5 and run

the program on the the CQ CKVM but of course we could also compile it to any other ISA um that we would want to um target with the fuzzer. Um so we generate this random pro rust program. Um you can see like a simple example um on the left. Um so you can see here that we we actually have a sort of a known expected outcome for each of these. So we know kind of up front what it what output it should produce. In this case it should produce zero. If it um if there's you know a bug in the ZKBM then it will produce uh the output coffee.

So on the right you can see an example of a bug we detected in Jolt. So this is a um and you can also see the the program that we minimized uh on the on the right. Um it's a bit small but basically the program um it it exposed the um completeness bug in in the CH prover and in this case the program was actually failing for this um multiply um high uh signed unsigned um instruction.

So this kind of shows that um and the father found this because even though this is not a very common instruction, we try to generate as many different um instructions as we can. the second step in in this um process is to do kind of regular vanilla ZKVM execution. And in this case, the fuzzer just runs the program um with some random inputs. And um there's basically two possible outcomes. Uh either at one point during the execution um there's a crash in which case we've exposed a completeness bug uh in the ZKVM or it could also um produce the wrong output. Um so in this

case we would have something that could be either um you know exploited uh to to get a a completeness issue or like a soundness issue. And on the right you can see an example bug uh we reported for Nexus where um there was an index out of bounds in in the prover and actually as you can see I mean it's a bit small uh but basically the program um required a specific uh input um that would trigger this um this panic. So it's also important for the fuzzer to actually find the right inputs to to invoke the program with.

>> And the >> the maintainer of plunky 3 uh Angus is asking have you tried fuzzing plunky 3? um not directly, but I think since I think several systems are using plunky 3, we might actually be kind of sort of like um implicitly um >> um fuzzing it um with like by basically running some ZK um VM that you know uses some primitives in BL3. >> Got it. And when you say um completeness bug with a crash, do you actually mean a prover livveness bugs in the sense that it's not a a cryptographic bug in that's enshrined in the verifier? You just need

to fix the prover and then that would start running again. >> Yeah, it's I think it's the the the latter. I mean it could be in any step. So it could also be in the verifier um in theory. So on run the verifier might you know expose some crash there uh which probably would be worse um but yeah that's that's essentially the idea that yeah >> okay so far involved >> in livveness issues um if you yeah you yeah have this >> is it fair to say that you've only found crashes you haven't found a statement which is fundamentally impossible to verify >> we yeah so this this these I guess would be the soundest bugs um um that I'll I'll mention now I think.

>> Cool. >> So yeah, so I mean you could get soundness bugs with what I presented so far. Um where like you produce a different output and that would you know that would hint at a soundness issue. Um but we specifically have something that we run after this sort of regular execution which is what we call like an adversarial um execution. So we have essentially created sort of a a patched version of these different CKVMs that we we target and they basically try to get generate an invalid trace and then um we run the program with the same inputs on this adversarial VM and there if we get sort of the wrong output because um you

know generates um something is wrong in the execution generates the wrong output uh then we take this proof and we try to verify it with sort of the vanilla unpatched um verifier and if that passes then that hints at a that indicates that there's a soundness bug. Um and on the right you can see an example where for uh jolt we we found a bug in that in the sort of handling of this um this uh load um the load instruction.

um where basically you could have loaded like there was essentially the the constraint um there was a constraint missing in how this was encoded and that um basically like during the execution you could have provided any value that was supposed to be loaded um and the prover this bug and we found three I mean in total we found three bugs of this type for three different um CKVMs. So yeah, so what's the conclusion? Um, so Argus is is the first fuzzer that detects these kind of soundness and completeness bugs in ZKVMs. It's still really like work in progress. Um, so we

started working on this only a few months ago. Uh, but it already found 11 critical bugs in three ZKVMs. Um and if you want to, you know, uh test your ZKVM, uh please feel free to to reach out and um yeah, happy to see what we can do. >> Amazing. Thank you, Valentine. And uh as I understand um the diligent security has recently spun out of of consensus. Uh and yeah, if you are a risk 5 ZKVM, do make sure to to chat with Valentin.

I'm not seeing uh actually no, there is one question. Does this further target completeness for the execution flow of the ZKVM allow? I'm not sure I understand the question. in any case, we are above time. Uh thank you so much everyone for making it uh this far. for all 82 of you. Um, and I'll see you all on the e proofs call number five. Thanks everyone. >> Bye.

>> Thank you. Bye-bye guys. >> Bye. Bye.