Keynote: Jolt: A Simpler Path to High-Performance zkVMs by Markos Georghiades, a16z

Transcript

Okay. Um, next we've got Marco Gregorus from A16Z talking about Jolt, uh, the ZKVM that they've been building in house. Welcome to the stage, Marco. Uh, Jolt, a simpler path to high performance ZK VMs. >> All right. Good afternoon. I'm Marco. I'm an engineering partner here at A6Z and it is really my pleasure to be here to tell you all about Jolt. All right, here's some Oh, the key uh the keys aren't working. Oh, I got it. Okay, quick disclosures and all right. Um I have to show you them. Sorry. Um this

talk is really about myths and misconceptions. So there's been a lot of great progress this year, but with this great progress, unfortunately, a number of myths have appeared about uh the conventional way to design a proof system. And so this talk is really about addressing some of these myths and uh pet peeves that we have here at Jolt. Before we get into the myths, we will first begin with some context that is very necessary. Now, as I alluded to, the progress has been quite good this year. And uh with this progress seemingly every proof system other than jolt has converged to a very similar construction and jolt as we will see is very different but I pose this as the final debate jolt versus hashbased

provers. So here are the metrics today and the the metrics that people care about. So if you take a p99 block today on eth proofs a stark prover is performing at about 14 seconds with 165090s. The proof size today varies a lot for a stock prover anywhere from 220 kilobytes to over 1 megabytes. The memory usage today is bounded but large and when I say large I mean 8 to 10 gigabytes. Jolt today is is about 70 kilobytes proofs and uh we are using 330 bytes per cycle proven. In 2026 we want to be at sub 1 second proofs.

Here are the main design choices in uh of ZKVM. So today most ZKVMs are designed for succinct blockchains as is Jolt. Jolt will be very effective for that. Jolt is also the only risk 5 ZKVM that I know of that is suitable for client side. Uh Jolt will not use recursion and will not use circuits. And this these two design choices are reflected in the fact that Jolt's core provers implemented in only 40,000 lines of code. Throughout this talk, I will be talk I will be mentioning a few particular upgrades. So in particular, GPU Jolt, streaming jolt, and lattice jolt. So just keep an eye out for those as I go through the content. All right, so let's get to the first myth.

The first myth is that we can just throw GPUs at the problem and we're going to get a faster proof system. All right, so to explore this myth, I begin with a fact. Fact, if I give existing ZKVMs today 2,000 GPUs, they are not going to prove ETH in one second. So why is that the case? Well, the implication is very clear. We have suboptimal parallelization. Jilts on the other hand has this property. I will just call it partition friendly data. It's it's actually very simple. All it means is that uh in this case I have an example of polinomial binding. It's a very common operation in Jolt. You can take the data the coefficients you can split it into chunks like four chunks. You put them each onto a GPU and each GPU is very

happy and it does its own work and there's very little latency and cross commmunication overhead. So Jolt is very friendly when you take the data structures of proving and you split it across multiple cards. Now, Jolt, other than being partition friendly, is also the fastest ZKVM today on a CPU. Jolt today is nearing 2 megahertz uh with a 32 core Thread Ripper. You will also notice that Jolt is very workload independent. What that means is that Jolt cares very little about the underlying workload. What matters to Jolt speed is simply the number of cycles being proven. I will also note that today 31 bit bit start provers are performing at around 3 to six megahertz with a single GPU and Jolt is dangerously close to that territory.

Right? So then I say Jolt will prove 1 second with 16 GPUs. The math is very simple. Take a P99 ETH block which is about a billion cycles. Jolt proves at about 2 mehz today and Jolt has this partition friendly uh property and so we expect an 800fold increase. And well the math says e blocks will be proven in under 1 second with streaming. I expect single GPU jewel to also be as fast as today 16 GPU stark provers. All right let's move on to the second myth that was all about these very large statements. Yeah and uh what about the small things over the client side? Well largely that has been neglected by ZKVMs. Um I have this fun app. This app is really the simplest possible wrapper

that I could make around Jolt. It is literally a simple function call into Jolt's CPU approver. I'm not a mobile dev, so I apologize for the bad UI, but um I'm going to just click this button and we're just going to see what happens. Um what this button just did is it's proving jolt on my phone. It's proving 30 cacts just for fun. Um and yeah, so the we'll just wait for it to finish. Okay, it's done. So um the proof finished in 4.7 seconds. It used uh the screenshot's pretty accurate actually.

Um this one used exactly 246.6 megabytes of memory and as far as I know it's the only ZKVM that's risk 5 based that is anywhere close to these metrics on a phone. So I expect Jolt will be the best uh ZKVM for client side proving and for big statements too. Yeah. So why do you want this on a phone? Well, okay. Current existing solutions for client side are not adequate. They first of all involve circuits and I want to kill circuits. Be very clear. I will talk about this shortly. Uh they have proof sizes that are just far too large and sometimes they do not have succinct verification and sometimes I've heard some ridiculous things like having to download verifier keys that are literally take longer than the actual verification itself which uh Jolt does

not have this problem and I yeah I think that's pretty ridiculous we had that in 2025. Okay, so I talked I mentioned circuits briefly. Let's talk about why uh why I don't like them. Um okay, Joel does not use circuits as I mentioned. Um in replace of circuits we have batch evaluation arguments. To be very clear circuits are just the largest source of bugs. They are and here on the right I have a code snippet which shows the auditable surface of a single instruction in Jolt. So it's like 10 lines of code. You implement the multilinear extension of the end instruction in this case and that's it.

The bottom line is that this is better for your auditor and it's also better for the machine that's going to extract this and do formal verification. So I think we would rather have uh instructions that look like this than circuits. And I hope you agree. Okay. So the second largest source of bugs arguably is that of recursion. So let's talk about recursion. What do people do today to control memory in a ZKVM? Well, what you do is you have this big execution trace. You chunk it up into a bunch of pieces and then you're going to prove each piece independently. Once you prove each piece independently, you have to aggregate them and then you get this final proof. You also have the burden of having to prove the memory consistency between each of these chunks. Now, why does this suck? Um, there's three main things. Number one,

it is very bugprone and at a protocol level, it is complex. Uh, some ZKVMs today spend twothirds of their time doing this recursion. So, it is very slow and some things some ZKVMs to make this faster have to use curves which defeats the purpose of being hashbased. There is also the minimum high memory requirement of 8 to 10 gigabytes which makes makes these ZKVMs infeasible for for a phone. Okay. So in replace of recursion we use streaming agile. Streaming is when I say streaming I mean a streaming algorithm does not have additional circuits does not have an additional pipeline and we are just streaming the trace and the uh the execution trace through the prover. Uh what's nice about this is you can easily tune uh your proof pipeline depending on

the desired RAM and number of threads available. Just to kind of explain how this works. So you have um instead of having to proof each chunk independently, you take one contiguous chunk, you feed it through the proof system and then you take the next chunk, feed it through and you continue until you pass through the trace. uh in the streaming paradigm you have to go multiple times over the trace since we are lazily uh evaluating it and particular OLOG end times um but what is what is nice about this is after the first pass you can parallelize this process and so um in practice for GPUs especially this is quite cheap okay to all the people out there who don't like curves and say that you know today jolt indeed uses curves we have a good answer for this uh enter lattice

jolt lattice jolt is basically just curve jolt it has the same asmtotics and concrete values as dory jolt does today but with module SIS assumption. So lattice jolt we expect to be four times faster than curve jolt today because of the fact that we get to use a 128 bit field. Um we will talk more about why we use such a big field but the point is here is that we expect lattis uh lattice jolt to have the same concrete values that the nice small 100 kilobyte proof sizes and we expect that the performance of CPU jolt will actually match or exceed current 1GPU provers.

Now in the end I actually expect because of Jolt's uniquely modular design that we will be able to support all primitives and the developer will just be able to pick whichever assumption that matches their post uh their postquantum risk appetite. We are still working on hashes but today uh lises and curves are great options for jolt right okay how we doing time yeah um we have one more uh point that we will make today so the prevailing approach that a lot of uh that start provers use um is that of 31 bit fields so what I mean is that say you have like a mole RS1 RS2 this instruction um what do stark provers do today well because two 16 uh

16 x 16 uh bit multiplication overflows a 31-bit field. What you have to do is this bite decomposition. So this like blue line here or this blue layer is uh bite byte decomposing uh each of the 64-bit registers and then now you're going to perform uh bytebyte multiplication and then you're going to concat the result back into the field. So uh what does Jolt do inside of this? Jolt uses a big field. uh Jolt can directly embed the register values or the RAM values into the field and then do a single field multiplication. Now it turns out that comparing the two approaches, so having faster multiplication or having a single field multiplication uh that you come out on

top by having one slower multiplication rather than doing the bite decomposition. that bite de composition creates a lot more work and uh this approach is one of the main reasons why Jolt is many times faster on a CPU today than other provers. All right, so let's do a quick recap here. I threw a lots of information out. So there were six things that we targeted today in this talk and uh yeah I'll just give you the rundown. Jolt today u does not have a GPU prover but we expect Jolt to run at 1 second or under with 16 GPUs. Jolt today is the most performant risk 5 ZKVM on a phone and I expect it to be the choice going forward in 2026 for client side proving.

Batch evaluations are both simpler and faster than circuits. Circuits are bugprone and they should die. And streaming is simpler and faster than recursion which is also a very brittle uh primitive. Jolt today works uh well with curves and will soon work well with lises. And lastly, we avoid this nasty biteby bite decomposition that makes other ZKVM slow. All right, that's about wraps up my time. Last thing here, here's a nice photo if you want of the do two different constructions. This is these are the main ingredients of Jolt for Starks. And yeah, that's it. Thank you very much.

All right, amazing, Marco. Uh, got time for a few questions. So, let's see here. Um, why are you currently not first on ETH proofs? How many assumptions do you have in the sub 1second block proof time? >> Right? So we don't have a GPU prover when the GPU prover is available or when we are faster than GPUs on the CPU then we will hook up to ETH proofs. That's the first part to answer your second question. Uh remind me >> um how many assumptions are you using I guess or or >> I mean there was just two things that in this equation. Um I will actually preface this by saying that people traditionally ignore how fast a prover is on a CPU because well we want GPUs for large statements but avoiding this

metric which I made it very explicit today makes it very hard to reason about how fast these provers are actually proving VM execution. So the two things to the assumptions made here is that number one jolt is the fastest prover on a CPU and Jolt is doing the least amount of work per cycle out of any prover system period and second of all Jolt is very friendly when we throw more hardware at it. So I expect because it is the fastest thing like the base amount of work and because it is very parallelizable and friendly when you partition it in a distributed system I expect Jolt will be the fastest prover on GPU.

>> Great. Um you have you have our Risk 5 64 iMac right now. >> Which ISO will you target in the long run? >> Risk uh risk 5. >> Okay. >> We we believe that risk 5 is a is a snark friendly uh um instruction set. Yeah. >> Is Jolt planning to do subblocks as well? >> Don't think it's necessary. >> Nope. Um okay. Why is being the fastest risk 5 based uh ZK prover on a phone important? If I'm on a phone to prove why would I not prefer WASOM?

>> Well, Jolt will work for WASM and for native execution. >> Okay. >> Yeah. >> Um >> I think it will be the as far as risk 5Z KBMs go will be the best for that. I think you can always do better with bespoke provers. Um but in the long run I don't see this as a maintainable solution. >> Let's see here is uh can you give more details on the parallelization of the execution? Uh which part the streaming or the or or one in particular? >> I wish I had the followup. >> Uh was this the was this the beginning or was this the slide?

>> Uh that's all I have. Um maybe we could go to the another question. Yeah. >> Um is streaming Jolt also super parallel friendly. You need an initial serial pass similar to other ZKVMs, right? >> Yeah. So you have to generate the trace once serially which is known to be fast on GPUs and then afterwards you can basically put these checkpoints and these checkpoints you can save the memory uh layout and then you can now do things in parallel. So yes uh it is quite friendly. Um this streaming laz this lazy evaluation of the of the trace has very little to do with the fact that the rest of the prover and the s checks are already very uh paralyzable.

>> Great. Thanks again. Uh, round of applause for Marco. Thank you. Thank you.