Proving Ethereum in Real-Time With OpenVM | Yi Sun - Axiom

Hey everyone, my name is Ye. I'm one of the co-founders of Axiom and today I'm going to talk about proving Ethereum in real time with OpenVM. So to give a bit of context, Ethereum has recently decided to embark on scaling via zero knowledge proofs. So I thought I'd start by saying a little bit about what that means. So today, one of the fundamental bottlenecks in scaling Ethereum is that when validators uh check if Ethereum blocks are valid, they need to re-execute every transaction in the block.

And so this involves a lot of database lookups and is fundamentally the binding constraint in increasing the gas limit. If we increase the gas limit too far, validators on small hardware would just not be able to keep up and that would obviously hurt the decentralization of the Ethereum network. Um so instead of doing this, Ethereum is switching to a model where execution of blocks is proven in ZK and then verified by each validator um in a way which is much faster and cheaper. And critically the verification is constant cost no matter how large the block is. And so what this means is that if we can scale the ZK proving of Ethereum blocks that will directly allow us to increase transaction throughput on Ethereum.

And so the Ethereum Foundation has a very nice website outlining this road map. Uh but the key figure is this. Today we have a block and every validator re-executes it. This is very wasteful as well as slow. And we're going to transition to a future where there's a prover that verifies the execution of the block and sends the proof to each validator to verify individually.

So that's both computationally much cheaper as well as more efficient. Now the key difficulty here is that the provers actually generate this proof within the Ethereum block time. Uh so within 12 seconds and we call this real time proving. And today I'm going to talk about how we're able to actually realtime prove Ethereum using our ZK infrastructure at Axium. So just as a quick refresher on ZK for everyone, uh what zero proofs do is allow a party called the prover which is untrusted to establish that they correctly executed some program in this case the Ethereum state transition function.

So the way that this works is that Alice the prover will claim hey I ran the Ethereum block the resulting state route is as I claim and Bob the verifier will challenge Alice to say hey I don't really believe you need to see some evidence and what is your knowledge proof lets you do is that Alice can generate in parallel to execution some cryptographic data which is called a proof and Bob upon receipt of that proof can know with a cryptographic degree certainty that Alice actually ran the program in an honest way even if Alice is a totally untrusted party. So Ethereum has decided to take an approach to writing uh these ZK programs called a ZK virtual machine. So when ZK was first invented, developers had to manually translate every program of interest into a mathematical object called a ZK circuit. uh which is a system of polinomial equations that somehow encodes this program. Uh as you might imagine this is pretty complex and very time consuming for developers to actually do.

So instead of doing that a ZK VM or ZK virtual machine allows developers to write in normal programming languages and handles all the complexity of encoding them into ZK on the back end. So this gives a much more natural developer experience and also allows us to prove the state transition functions which are actually implemented in Ethereum execution clients without modification. So it also makes the security story much simpler. All right. So today I'm going to tell tell you about the ZKVM that we're building on Axiom.

It's called OpenVM. Um, and our design philosophy for OpenVM is to keep things very modular and extensible while not compromising on performance. Um, so we've achieved this by introducing a new no CPU architecture for our VM as well as maintaining modularity on the VM ISA level. And finally, we allow developers to access OpenVM to prove arbitrary Rust programs uh to make it easy for uses on chain. So we recently announced OpenVM 2.

0 and to jump to the end, we're able to prove Ethereum in real time with OpenVM 2.0. So what that means is that over a thousand blocks that we sampled starting from block 24 million, uh we have a P99 proving time of 11.8 seconds and an average proving time of 6.7 seconds on a cluster of 165090 GPUs.

And the idea behind this choice of cluster is that these are the standards that the Ethereum foundation has established to make proving uh distributed enough for anyone to participate. Uh for reference the idea is that 165090s takes around 10 kows of power draw and that's what you might expect from a typical residential uh power connection. Um as you can see we've made a lot of progress uh in the last year since releasing OpenVM in early 2025. Uh in the figure on the right uh we've incre we've decreased proving time by about 60x over the course of the year uh and we expect significant future improvements in the coming months. So now that we're actually proving Ethereum in real time we decided to evaluate OpenVM u in comparison to a more traditional processor.

Um so we took a standard CPU benchmark called coremark for embedded CPUs and looked at how fast we could prove that program with openVM. Um so you can see in the graph we started with one GPU and scaled up the cluster up to 16 GPUs. Um and that allows us to scale the proving from about 11 MHz to 139 MHz on 16 GPUs. And as you might imagine, if we increased the number of GPUs, that scaling would continue. Um, so we're actually already in range of processors that were in use by, you know, normal humans maybe 20 years ago.

And we actually expect to converge to the rate of modern processors in the next year. All right. So a little bit about how we achieve this. Uh, so OpenVM 2.0 introduces a new zero knowledge proof system which we called swirl.

So it's a multi-linear proof system that's customdesigned for the ZKVM workload. And a critical component of squirrel is that it uses a polinomial commitment scheme called WR. So that's a hashbased commitment scheme that has a very cheap verification or opening. Um so swirl has a lot of good properties. We're able to deliver 100 bit provable security.

Uh it's postquantum and critically the proofs are pretty small. So we're able to get under the Ethereum Foundation target of under 300 kilobytes and we don't use a trusted setup. And finally, one very appealing thing about Swirl is that we were able to design a very fast recursion circuit to enable us to parallelize proving across many GPUs. Um so this recursion circuit achieves good performance while still allowing us to have enough dynamic control to handle our recursion pipeline. Uh so if you want to learn more about the technical details on swirl, you can check out the link.

Um so more on the security side, we actually recently announced that we formally verified the riskfi front end for openvm in lean in collaboration with nethermind research. And so what this means is that um we're able to actually use this lean forum theorem prover to check that the zk circuits that make up the openvm zkvm actually match the official specifications for risk 5 uh published by the creators of risk 5. And the good news is that throughout this verification process we were able to cover all the op codes and we found no bugs in the front end. And so this gives developers using OpenVM some formal guarantees on the security of what they're actually doing. And lastly, one big contributor to the latency speedups in OpenVM 2.

0 is that we introduced an AOT or ahead of time single pass compiler for RIS 5 to x86. And so what this means is we're actually able to cross-execute a risk 5 on an x86 machine at 3.8 GHz. So that's not quite native. Native might be a bit higher, but we're getting very close.

Uh it turns out that when you prove in parallel in ZK, uh execution, namely just executing the program at all, is becoming a very significant part of the latency. And so this AOT execution went a long way in getting us to that real-time target. So what's next? Um so for Ethereum there's now a pretty concrete path to introducing ZK verification for L1 validation. Uh there's an official EIP EIP 8025 that introduces optional uh ZK proofs for validators to verify execution and the consensus clients have started actually integrating uh ZKVM proving and verification into the pipeline.

That's scheduled to roll out I think later this year. And afterwards um there's actually a plan with native roll-ups to reuse the same infrastructure to allow uh L2s to tap in to this level of ZKverified Ethereum security. Uh and the critical thing about this transition is that the throughput of Ethereum which is currently bottlenecked by you know hardcore database engineering is going to scale directly with improvements in ZK proving. So what does it mean for developers? Uh there's two big takeaways I would say.

First is that Ethereum ML1 is going to scale throughput dramatically. Um so this is going to lower gas fees and also reduce network congestion by just increasing the valid block gas limit. Um and on the application side through these improvements that were largely driven by L1 um rollups and privacy applications can also benefit. Um so the DevX and just pure cost performance of ZK has improved you know as I mentioned about 60x in the last year and so applications can also benefit. So outside of proving Ethereum L1 uh at Axium as a company we do help teams integrate ZK into their products uh through product design, custom acceleration of programs using OpenVM and finally actually running the provers with uh orchestration and GPU acceleration on our API.

Um so over the last couple months we've been working with lighter to uh add an EVM based rollup that interoperates with the lighter exchange. Uh we've been finalizing scrolls rollup on mainnet for close to a year now and we're also working with some teams in the hyperlquid ecosystem. So yeah, if you're interested in learning more about OpenVM, you can check out our docs and if you're interested in working with Axiom on implementing ZK in your application, you can reach out at our chat form. Thanks for coming by.