Keynote: OpenVM: RTP for Ethereum L1, the Modular Approach by Yi Sun, Axiom

Transcript

This afternoon we're going to start off with we've got uh six talks. Uh we're going to hear sort of an architectural overview of six different uh ZKVMs. We're going to start off with uh OpenVM. They're going to be uh Y is going to speak about real-time proving for Ethereum L1 the modular approach. Ye thanks for being here. Hey everyone, my name is Ye. I'm one of the co-founders of Axiom and yeah, I would love to tell you about how we achieved real-time proving for Ethereum using OpenVM.

Maybe if the slides will work, I can tell you more. Okay. Oh, click. Okay, great. Cool. So, so first of all, OpenVM we call a ZKVM framework um because it is meant to be customizable and extensible. Uh what that means is that although we support certain ISAs, we don't like to bake that into the framework and we want to allow developers the choice to modularly build the ISA that they need

for their purposes. Um while still using the same framework. Uh so currently we offer a Rust front end and also use what we call a no CPU architecture to enable all of this. Now to talk more about the modularity at the ISA level. With OpenVM, we allow developers to build an ISA through what we call VM extensions. These are groups of op codes that interoperate over over common memory spaces and developers can add or modify extensions while importing the core openVM as a library. Uh so for example we have risk 5 support through an extension and core openvm does not know about any particular ISA. So out of

the box openvm can prove rust programs but developers can also customize by creating their own VM extensions for workloads of their choice. Uh we believe there are some workloads like machine learning inference or particular signature schemes that will require this approach. So now let's talk about what everyone is here for which is how to apply OpenVM to uh Ethereum. So first of all we launched uh at the beginning of the year and at that point OpenVM was frankly not very efficient. Uh we've been able to make about a 3x improvement every 3 months since then. And on a benchmark block a block 21 million uh we now have subsent proving and also real-time proving. Um,

so overall we've been able to achieve over 30x performance improvement on both cost and latency. And so as everyone saw in the demo, we're now able to prove Ethereum in real time um on 32 GPUs. Um so in this histogram you can see that our P50 latency is around 7.7 seconds and we have a P99 latency of a little over 10 seconds. Uh this is on a range of 1,000 recent L1 blocks uh from I believe yesterday.

So in this talk I wanted to talk through three areas of our architecture uh which I thought were particularly relevant to real-time proving. So that's our no CPU architecture which is the way we construct OpenVM to allow a modular architecture. uh the optimizations we made to execution through ahead of time compilation and finally our overall distributed proving pipeline. So our perspective at with openVM was that existing ZKVM designs really kind of overfit to physical processors. When you design a CPU, of course, there's a physical chip and it's very hard to make it configurable and you must specialize

to a specific ISA. A lot of ZKVM designs kind of emulate this by having a central CPU circuit that knows about every op code and coordinates all of the VM activity. Um, so with OpenVM, we've introduced a what we call a no CPU architecture where we do just that. We remove the CPU and in ZK we're actually able to constrain execution consistency without doing it in a single chip. We're somehow distributing it through a consistency check with randomness. Uh this has two benefits. Uh the first is that we're able to just reduce the trace size by removing this large CPU circuit.

And the second is that we're able to plug in new op codes into the system without imposing changes to other circuits. And so this makes modularizing the ISA much more straightforward from a development perspective. Okay. So in our distributed proving pipeline we have roughly three steps. The first is that we actually have to execute the guest chromoggram of interest uh the Ethereum state transition function on the CPU. So that's done in serial. After that we execute again in pre-flight execution to prepare for trace generation and then finally we do GPU proving. Um, so as you can see, the only serial step in this

process is the CPU execution. And as a result, for something latency sensitive like real-time proving, it's a pretty critical bottleneck. Um, now the core challenge when proving an ISA that is not the exact same as the one running on your CPU um is that you essentially need to interpret the ISA. And we went through several phases where we discovered that interpreters are pretty slow. If you implement a naive interpreter, maybe with handwritten Rust, you'll probably achieve something like 20 to 50 MHz. Um, if you go a little bit deeper and add things like tail calls, you'll get to something like a couple hundred mehz. Uh, so we did this previously and we had risk five

execution at about 380 MHz. Um, and in our push for real-time proving, we implemented ahead of time compilation of the state transition function, namely transpiling every risk 5 op code to x86 op codes and storing as much as possible in the lower number of registers. Now, one particular difficulty in doing this in our modular design is that we needed to handle extensions that we did not want to translate to x86 assembly.

for example, things like the catch hash or elliptic curve uh pre-ompiles. And for this, we had to support mixing and matching handwritten x86 assembly for risk 5 um and just native Rust that's already optimized for these special operations. So to give a sense of the scale of the results, I said before that with our best interpreter, we're about in the 300s on 300 MHz on execution. Uh with ahead of time um execution, we're able to achieve uh over 2 GHz. Uh which is roughly half of native execution. We think this is pretty close to best possible since for every risk 5 cycle, we're using approximately two x86

cycles. Um and as you can see on a relatively tail block um in the 23 millions with 43 million gas uh this decreases the execution by about a 3x. You may ask why it's not a you know 8x and the answer is that there's already a significant amount of the execution of the block that is not in uh emulating risk 5 but rather in emulating pre-ompiles. Um so this was a big step in reducing the latency of the only serial component in distributed proving.

So after distributed proving or a after execution um the proving process for openvm is fully parallel. Um so we do trace gen fully on the GPU and then we do uh proof generation also fully on the GPU to remove any sort of hosttodevice memory transfer. All right. So, what's next? Um, as everyone has seen in the demo, realtime proving for Ethereum is now a reality. And for ZKVMs in general, we feel like we've reached a point as an industry where performance is on a path to being not an issue for applications. And what

we think will be important is actually flexibility and customization for different applications. Uh so to that end uh on the OpenVM side we plan to add different ISAs and frontends for example support for things like RV 64 or web assembly as well as the ability to synthesize pre-ompiles in a more automated fashion rather than writing them always from hand by hand. Uh moreover, we now want to cash in our modular design and have the ability to apply OpenVM to more domain specific computations with extensions that are very outside of a typical ZKVM compute pattern. So look for more from us about that uh in the next couple months.

So if you want to learn more about OpenVM uh you can check out our doc site or our GitHub. And if you're interested in working with the Axium team to implement OpenVM for your application, uh you can check out our link on the slide. Uh so thanks for listening and happy to take any questions. [applause] [snorts] Thanks so much, E. Uh we've got one question here. What is the most exotic and interesting ISA you see people looking to implement in OpenVM's framework?

feel like the most exotic ones are different ways to implement web assembly. Um, and I think the biggest advantages of web assembly are that it offers a more virtualized um, embedded systems backend for different languages. Um, but there are certain things aspects of web assembly which make it a little bit more difficult to implement it as ZKVM. So people have been trying out different intermediate forms on OpenVM. >> Excellent. uh what does success look like for OpenVM? >> Yeah, I I would say the broader problem that we wanted to solve with OpenVM is the ability to apply ZK to a range of computations that really matches the type of computations that happen um in

the broader world. Uh as an example, if you look at a typical application, there's a database uh which is currently not really a concept in ZK. And if you want to emulate something like that in ZK, we feel you need a more general architectural framework. So for us, success would be that there's a smooth pathway for developers to combine things which look like ZKVMs which with things that currently look like custom circuits. >> Amazing. Thank you very much. And uh yeah, great work. >> Thanks. [applause]