Keynote: zkSync Airbender: Fullstack zkVM Customizations by Porter Adams, MatterLabs

Transcript

All right. Next up, a gentleman that needs no introduction, Porter Adams from uh Matter Labs, ZK Sync Air, Speaking about Airbender. Uh so, welcome to the stage, Porter. We're going to talk about ZK Syncs, Airbender, the full stack ZK VM customizations. Great. uh you just advance with the keys. >> Awesome. Thank you all for having me. I'm super excited to talk about Airbender. We've had some really cool announcements as of yesterday. So, I will get right to them. Um and then I will connect it to ETH proofs initiative and the entire Ethereum ecosystem just talking about full stack ZKVM

customizations in general. So, we did it yesterday. Ethereum airbender proves Ethereum with basically a toaster. Uh we have our 2GPU benchmark over there on the left and uh just to show that we can get it under 12 seconds, we have our 8GPU benchmark on the right. Um so we're very very pleased with these numbers. I know some people I've learned have $100,000 of GPUs at their houses. I do not. So for home proving for me, two GPUs sounds much much more reasonable. And we can also start like scaling Ethereum and raising the gas limits sooner uh thanks to much lower hardware requirements for this. So yeah, we did it. Now I do just want to do a little

victory lap on stage while I'm here, which is to not underestimate the progress of ZK. Six months ago, there was a very serious post on the Ethereum Magicians forum about relaxing prover hardware requirements for the next few years. And I of course thought this was very silly. I don't know if anyone listened to me back then. Hopefully you will understand now. Uh some teams will achieve real time at home proving before 2025 is over. We've done it. Um and so of course now uh the question is if we scale the gas limit though ZK performance also needs to get better.

And my bet is that like you've seen how far ZK has come in the last like 6 months. I think the progress is going to keep continuing and I think CK progress is moving way way faster than these people will get together and raise the gas limit. So it's my challenge to you all Ethereum ecosystem raise the gas limit as fast as you can try to keep up with ZK. Um so just to kind of like map out the hardware requirements getting lower. Um, we're trying to shift everybody over to the left side of the screen where we just have two GPUs and keep that proving time down as low as possible. So, really great work by the Matter Labs cryptography team. Um, especially want to shout out to them. The engineers

worked super hard on this and so yeah, super proud of their code. U, and the basically a toaster is from Justin Drake. If you don't like that, be mad at him. He's the one who said it. Okay, now I'm going to explain how this was all possible. Uh quick background first on Zikasync OS. This is um so previously we had Zikasync prover and sequencer code bases were two separate things. Uh we kind of wrote like a fully optimized prover and then separately we had to write like our sequencer and every upgrade we had to upgrade the sequencer and then upgrade the prover and then make sure that they still matched and this was a horrible way of doing things and actually limited the number of upgrades we were able to do to zay which was very painful. So we've

replaced all of that. Now we've worked with sort of like an abstracted execution layer. Uh so the prover and kind of the execution layer are all separate. Uh we will compile the execution layer to x86 and run it for the sequencer. We will compile the execution layer to uh risk 5 for the prover. This whole sort of architecture here we call zinc OS. Uh it includes a bootloader to start the system. Uh what happens in the system stuff is like input output handling. that's going to be the same regardless of which execution environment you're going to use. Like you're going to need some inputs and outputs. And uh the slide kind of hints at that we will be able to support multiple execution environments.

So if people are interested in like web assembly or other things besides EVM proving uh that is like built in to kind of be a modular codebase. So that zinc OS is going to come back again in a couple slides. Airbender. This is our new risk 5 ZKVM. I don't know if it's still new. I think it's pretty new because it's not quite on mainet yet. But here we are. So anyways, the instruction set risk 5 32 IM arithmetization a proof starks fry commitments mer 31 prime flake dos hash and like just a regular permutation argument for the memory argument. And so whenever people come to me and say like porter airbender like great job on all the benchmarks you're super fast you

must be using like some crazy cryptography or something. And then I show them this and everyone says that's the same stuff that everyone else uses and this doesn't really answer any of my questions. So isn't this like kind of the same as everybody else? Like where does the performance really come from? Fullstack ZKVM optimizations. Title of the talk I promised. So I want to start talking about how airbender is like kind of co-designed with the hardware in mind. We really really focus on this uh in like extreme detail of like every aspect of the hardware. How fast can we like pipeline things to the GPU? How much size like what size data structures should we use

to fit inside the GPU? And like everything is done with the hardware in mind. That's kind of vague. So I just want to show you a little example from one of our chats. Uh, Alex Blasov, our uh, co-founder is asking a question about GPUs. We would like to use 5090s for RAM reasons. That improves recursion at later stages. Recursions like how many circuits can we kind of compress down at once? Uh, is that fine? 5090 raw computational performance plus 20% top 4090 as I explained. So, uh, and then Justin Drake turns this down. 5090s are great for cluster proving, but for the single GPU tab on ETH proofs, they want to keep using 4090s. Alex Blasov says painful. Now, for most people, like it's

just a 20% performance hit. Like what's the difference between an RTX 4090 and RTX 5090? Like 20% like big deal. But we've written our code so that it like fully maxes out the space on a 5090. And when you just take away that 20% space on the 4090, now you have to kind of chop things up and like the maybe it doesn't fit in memory anymore. And so like that's going to slow things down and then like it's going to slow down recursion later on because now you add like yeah it's just everything kind of goes wrong. Uh so we we really try to optimize like all of our choices from the beginning have been specifically about the hardware. So uh we also optimize the cryptography a lot. Uh

don't waste any circuit variables any risk five cycles. There is kind of some interesting work there but not everything fits in the presentation. So got to go quick. I think this applies to lean Ethereum a lot because we're going to want eventually probably hardware diversity and ZKVM diversity. Um, and so if we want to run like any ZKVM with any hardware, like already Airbender takes like a performance hit if you use 4090s instead of 5090s. And if you want to use like, you know, different types of processors besides CUDA or something, uh, there's probably like a lot of work to do here. And my point is just that like you will lose some performance.

My like probabilistic outcome is just that everyone's going to wait until ZK is so good that it's okay to take this performance hit and have the diversity. But it is interesting to note uh as we think about the long term how we're going to match different hardwares with different provers. Uh Zayn OS and Airbender were designed together. So something relatively unique that Justin mentioned this morning and about Airbender and Zeusync is like we don't just take an L1 execution client like ref and compile it and be done. Uh we've written our own kind of execution client within for the EVM within zkync OS. And so this I think has led to like a very optimized kind of simple codebase that is easier to prove. Uh, I mentioned

this in the panel this morning too, but the the regular L1 clients haven't really been written kind of with proving optimizations in mind. And so like they've been written for normal hardware, which makes total sense for them. Uh, but as we switch over to this, uh, probably like the L1 teams and the ZK teams are going to have to kind of collaborate together to make sure that we get all the optimizations across. Uh uh one cool thing to note about Zaync uh OS is that we're able to uh do double resource accounting with both the EVM gas costs and the prover gas costs. So a lot of ZK teams will whine about like the gas costs of specific op codes. I'll still do that at the end of my presentation. We should change them. Uh

but it's not a big deal for ZK sync chains because we can just track both costs and like charge appropriately. Um all of this I think is going to be very solved by uh lean Ethereum. Uh there's kind of lots of ways to yeah match the L1 client teams with like all the ZK teams. Uh risk 5 like native code inside Ethereum feels kind of far off. So I won't really address that. And then yeah repricing the gas costs is going to take like 5 minutes once we decide to do it. So not really worried about any of the things in this slide. Just interesting to think about. Cool. I will give some suggestions to Ethereum. Uh we strongly request that we change the

Merkel Patricia tree to something more ZK friendly. Uh ideally all the values in the tree would be constant like non-variable sized. Uh adjust the gas costs specifically for this these op codes. Uh we want the explicit code length in the accounts. This is going to help with um like yeah checking the code for smart contracts inside the ZKVM. Uh knowing that is quite nice for proving uh and we don't like the catch hash function. Uh if we switch to binary trees strongly prefer Blake 2s cool just want to say Zikasync is very proud to help Ethereum. Uh million TPS realtime proving home proving believe in something. this is all coming like the

progress in this field every single day is really amazing and it's really cool to be part of this industry and this ETH proofs initiative to help make this all happen. So with that, thank you very much. >> Great. Thanks Porter. Okay, we've got some questions. Got five minutes to get through this. I think you got quite a few. Um, how is 17 seconds average real time with 12 second slots? It's a little slow. That's why yeah, the two GPU benchmark is probably not quite there. We probably need four GPUs long term. Uh we did eight because obviously we got this kind of ready like yesterday. Uh so eight just shows you like all right, we actually can cross the threshold. Uh we do have a lot of

optimizations still to come. >> Both are on ethofroofs, right? The eight and the two. >> Yes. Um, so there's still optimizations to come, but I would say it's fair to say that the two is not quite real time proving as of this moment, but by the time people like watch this video on YouTube, we might be there. >> Awesome. Okay. Uh, do you think that Airbender can forge a false proof? Do you think I can forge a false proof for Airbender with a toaster as well? >> Uh, I think it would be difficult. I I will say like I would challenge like I I know people are still worried about the security and we will like you know improve the number of bits but I think I

could find a bug in any of the ZKVMs faster than someone could do two to the 80 like bits like breaking of security by just using large computers. So yeah. >> Excellent. Thanks very much. Thank you.