Jolt: Making Client-Side ZK into a Commodity | Andrew Tretyakov - a16z crypto

Hey, uh, good morning everyone. My name is Andrew Trechikov and, uh, I'm engineering partner at A6 Zcrypto and the core maintainer of Jol ZKVM. And today I will show you how we're going to turn uh, client side proving into a commodity. So before we jump into client side proving I have two things I have to show you. The first one is this uh legal disclosure that the legal team made me put on this and the second what I want to mention is that we have successfully scaled blockchains with ZK.

Uh unfortunately the stage next door doesn't realize this yet but 10 days ago layer zero has announced that they're going to launch new generation of blockchain called zero which is going to have unprecedented throughput. They're going to have like two million transactions per second. And right now they are using Jolt to prove at the speed of 1.61 gigahertz. To put that into perspective, Ethereum to prove Ethereum in real time, you need like 50 megahertz.

So this is already like passed the benchmark of proving Ethereum in real time and we're already almost at the benchmark of proving CPU in real time. Now as you can see by the tweet of co layer zero they are planning to launch a terahertz cluster very very soon. So terahertz cluster basically means it's like 20,000 times bigger throughput than right now Ethereum has. So I think this clears the stage for the fact that scaling of the blockchain is solved fully and now we can transition to the client side. So the client side has been very very stagnant in the last four years.

And to prove this you can look at the applications that we had in the last four years. Specifically all of these like Zcash, ZK email, Zupass, Rail Gun, ZK login. All of these applications they have been around or like their counterparts have been around four years ago. In the last four years, we have had no innovation in the client side ZK space. Every client side ZK app that exists today is a singlepurpose circuit.

It is like handbuilt with a very very simple logic. We have made exactly the same mistake with ZKEVMs four years ago when we had a bunch of teams building their circuit ZKVMs and they failed. All of them pivoted to using ZK VMs because there are three reasons why. There are three reasons why ZK why circuits don't generalize. The first one is circuits use wrong computation model.

The second is that circuits fully fragment the ecosystem. And finally circuits are very very prone to bugs unlike ZKVMs. Let's go through by one by one by one. So your CPU proves stuff in like nanoseconds but the prover on the phone takes minutes to prove stuff. Why is that?

There is a reason because circuits are optimized for algebraic workloads. They are not optimized for standard bitwise operations. Hash functions spun up like the new type of program has been created just to just to be able to zk prove it like Poseidon hash functions. Right now circuits they're basically at most proving Merkel membership proofs using these hand optimized hash functions and also like maybe some simple group signatures. But what we need to prove is like standard cryptography.

We need to prove shadow 56. We need to prove ECDSA. We need to prove RSA. And these are like not hard operations. For example, ECDSA is the most complex listed and it's only 250,000 risk file cycles.

CPU can do that in a in like nanoseconds. So something is wrong here. We basically need to prove bitwise operations but we are optimizing to prove algebraic operations where it's like multiplications and additions. That's why when we were creating jolt we had to pick binary operations as the core core primitive up top. You can see how right now in a circuit you would do like a sore operation which is a very very simple operation.

You would be separating your numbers into bits. Then you would be doing bitby-bit calculation and then finally you would be composing back into a final number output. This is like a thousand constraints for one one single operation. Compared to jolt where we encode instructions as polinomials and these polinomials they are natively represented like the inputs to the polinomials are binary. So you just evaluate polinomial very very quickly at ones and zeros and this is like much much faster for what we need.

Now the next point is that circuits they fragment the ecosystem and what I mean by that is all of the circuit stuff that exists right now it is incompatible with each other. The circum is incompatible with Halo 2. Halo 2 is incompatible with noir. Nothing is composable together. In addition to that, every time we have a new ZK project, the first thing they do is they fork someone else's stuff and modify it at the lowest level possible.

They just fully kill composibility. That's why in the last eight years of developing ZK, we have not been able to settle on a standard. The ZK EVM era has proved this in a sense that we had Polygon, we had Scroll, we had PSE, we had Tao, they were all building the same thing independently. They could not coordinate their efforts. Even though some of them were both using like Halo 2 for example, they could not build the same thing.

They were building completely different things. That's why they got fully wiped out and replaced with ZKVMs. Now that's why you need to pick an ecosystem that already exists. We decided to pick risk 5 because risk 5 you can basically compile any program that has been built in the last five years. Sorry not five 30 years to risk five.

Any rust program any C program can be built to risk 5. So we just inherit the existing ecosystem that had a lot a lot of audits that had a lot of security review and basically we just latch onto it and expand it. In addition to that risk 5 is very very zk proving friendly. All of the instructions are very very simple. Next thing is bugs.

The currently most of the circuits have like 400,000 lines of code while jolt code has only 40,000 lines of code. You can compare circuits and jolt in a sense that every new circuit you write it has to be formally verified. It has to be checked for bugs. It has to be audited. And big circuits that we actually need to prove, they are too complex to be formally verified.

They are infeasible to for formal verification at all. and you have one missing constraint. There is a soundness bug altogether compared to a Rust program. You write a Rust program, it's much much easier to support spot a logical buck in there. In addition, Jolt verifier is very very amendable to formal verification because Jolt has only 10 lines of code per instruction.

This is very very easy for machine to extract and formally verify. So, ZKVMs have solved scaling. Why have not ZKVMs solved client side? Why is client side so behind on this? And there is an answer because ZKVMs were not built for client side.

All all the snark engineers and snark designers they were building for succinctness. They were building for scaling of the blockchains. And this does include jolt. So if you look at this like chart, this is a chart of Jolt Jolt prover speed relative to the program size. So the smaller the program, the slower the jolt prover is.

This is true. But what we noticed is that the right architecture it generalizes. And what I mean by that is all our snark design choices using of sum check algebraic commitments not no using not using recursion lack of circuits all of that fits into constraints of client side proving. It is fast it is very low memory and there is no heavy pre-processing. But there were still two points missing that we needed to fix before we could go on the client side.

And the first thing we needed to have wrapping. What I mean by wrapping is after your ZKVM generates the proof, that proof is just too big. If you take a look, the gross 16 proof is like 128 bytes. Nothing compares even close to it. Nothing else can go on Ethereum right now.

And that's where most of the privacy applications have to land. So there's absolutely no workaround. You have to you have to uh wrap your proof. And the second part is zero knowledge. Contrary to popular belief, ZKVMs are not zero knowledge.

They do not provide zero knowledge. I think this term is very very terribly misused because once again ZKVMs do not provide zero knowledge property. They only provide success property. They should be called succinct VMs. Jolt is the only ZKVM that since this Monday is finally ZK and we achieved this property very very easily using a called the new protocol called blindfold uh which relies on like the old older Nova folding schemes and we basically this is very very cheap.

We have no prover time uh increase and we have like 3 kilobytes proof increase. So once again if you can't uh if you're not zero knowledge what happens is that you need to wrap but wrapping part is very very expensive. No ZKVM can do wrapping on uh on the phone currently. So basically what if you look at the chart on the right your phone generates the proof the proof is currently big put like any any ZKVM proof is there. Now you have to send this proof to a server to do the gross wrapping.

If your proof is not zero knowledge, which is the case with all of the KVMs, you basically just disclosed all of your information, all your private information to the server. This is basically absurd. You cannot send any private information to the server. And that is why you do need to what we call native zero knowledge. That is what Jolt has achieved recently.

And this is like a very very big breakthrough in the ZKVM design. So in addition to that, Jolt will also support uh wrapping on the client side but with slightly bigger proof size. We will have roughly 6 kilobytes proofs and the wrapping time will take less than a second on the on the client side on your iPhone. The next thing I want to show you is Jolt running in a browser. ZK Jolt is the only ZK VM that can run in a browser today.

And that is mostly because every other ZKVM is constrained by memory. They all require recursion to manage their memory. And Jolt fits in the constraints of Vasom which is basically 4 GB. And to be honest, we should be targeting like 2 GB for client side proving today. Jolt is using only 300 bytes per riskfi cycle which is basically allows us to prove multiple millions of cycles on the client side very very easily.

For example, this very very simple shot 56 program is has been proven in like two seconds and that is without any optimizations. To put this into perspective, all I took is I I took the Jolt uh I took the Jolt prover I compiled it to was and I put it in a browser and I called it with with JavaScript. This is very unoptimized and I know at least two acts possible of optimizations there. You can yourself go to jolt proof right now and execute this. And I will actually do this right now.

So we can click the generate proof button. And we have the first ZKVM running in the browser. If the Wi-Fi is going to work to load the pre-processing. All right, we have loaded the pre-processing and we run the proving. The proofing has finished in 2 seconds.

Uh two and something seconds. It takes 3 seconds on an iPhone and the proof size is like 50 under 50 kilobytes which is which is great for ZKVMs but still requires wrapping. So on this point um I on this point I will I will do a quick recap of what we've talked today about circuits failed with scaling of the blockchains. We have made this mistake with um when we were trying to code ZK VMs the ZK EVMs a lot of the teams have failed to do this. There are three reasons why they all use wrong computation model.

They don't prove what we need to prove. They prove a completely different thing. They prove algebraic operations. Jolt natively proves binary operations exactly what is required. In addition to that, circus fragment the ecosystem.

In the last four years, we have not been able to establish a standard. We basically had the ecosystem fully fragmented and separated. That's why we have not been able to get the network effects compound and accelerate ZK development. Instead, Jolt mounts itself to the risk 5 ecosystem and inherits all of Rust and C. Finally, all of uh circus is code is completely unuditable and not possible to formally verify.

And of course, like there's like some small circuits that can be formally verified, but anything that we need to prove cannot be formally verified. Jolt on the contrary is very very easy to formally verify. Finally, Jolt is the only ZKVM that can run in the browser and that is provides native zero knowledge. Whenever you generate a proof on the phone, it is already zero knowledge. It provides privacy for you.

That is what we need for the for this for the ecosystem right now. Jolt is the only ZKVM business property since this Monday um on this. Thank you for your attention. Um,