Keeper: Turning Geth Into a zkVM Guest Program | Guillaume Ballet - Ethereum Foundation

All right, up next we have Guomle with on the core GU team and he will be doing a talk on turning GU into a ZK EVM ZKVM guest program.

Thank you. Um, I've been uh trying I'm going to to help Kodi a bit trying to to get the other buzzword uh the buzz word that is currently uh uh rampant in the in the Ethereum world um to to to get a bit more popularity here at at East Denver. Uh so far it's been mostly AI, but we're trying to to keep the ZKVM uh uh dream alive. Um, if uh I assume you watched uh Cody's uh Cody's uh talk. So, as a quick recap, uh we're going to put optional proofs um in blogs presumably this year.

Um there's uh there's a road map that should have been published today or will be soon. Um and it's um it's going to uh at least in the road map u proofs are required to to be attached in blocks uh by 2028. Uh now this is uh this is like an open heart surgery in the middle of the protocol. Uh so any uh any good engineering practice would uh would exert would suggest to exert more more caution. Uh but we're more uh I would say we're there's more of an accel accelerationist vibe at the moment.

So we're going to do it anyway. Um and uh as a result um I would say um the the sensical thing is to reuse as much code like because all those ZKVMs they are very uh still very experimental. I mean they're they're getting more mature but they're still pretty young. There's a lot of issues found with them. Um, and as a result, we want to uh reuse as much validated code, things that have been running in clients.

Uh, so that, you know, when we drive this car over the cliff, at least we've got our seat belts on. And, um, that means that not only we need to uh to reuse clients to write those ZKVM guest programs, but we also need uh them fast. And uh, what is a guest program? Um, one piece of detail that is quite important is that today a ZKVM is more like an embedded target. So if you know what a Raspberry Pi 0 is or a fly sweatter or all those little boards that don't really have an MMU that don't so memory management unit, they don't really have a lot of advanced features that you have on your laptop.

Um, so it's pretty bare bones. And so you have uh the guest program uh which is written typically in C in Rust uh in Zig if you're crazy like me and uh it runs then on a VM and this is a special VM that emulates an architecture and that VM will produce traces and then below the hood there's some ZK magic that I'm not going to get into the details of which I'm not going to get into uh but the idea is that the proof is built from from that. Now if you look at the way uh regular client is written today and of course the reference being guest for me because that's what I work on. Um the program runs uh on uh well uh there's the program and then uh it's relying on something called the runtime which is a set of functions that are provided by the compiler and then the runtime itself relies on an OS an operating system and then the OS runs on the CPU and that gives some sort of an impedance mismatch because if you just put the guest uh pro like the the program itself on the ZKVM this is not going to work. it's going to try to make calls and no one's going to answer those calls.

So you can't prove anything. So that's the that's the big uh challenge right now to to ship something from a language that has not been designed for this. So that would be uh mostly Go and C which means G and Nethermine which are the two most popular clients on the network right now. So so there's a bit of a challenge here. So there's really the question at the core is who's going to do the the compatibility work?

Um there's are there are two options. The I would say the the one that seems this sounds the most easy if we just say well we just have to only accept uh uh guest programs written in uh languages that are embedded friendly. Now it might sound like this is easy but it's actually not so easy because even if you take C has a lot of libraries that assume an operating system. Rust also um so you do you have a C without what's called a std std lib or rust in a mode called no std um you know you're not going to even with the best language you can find or the most suitable language you're going to not be able to write any type of uh program like every type of of program you're going to to be constrained so that's the drawback uh the advantage is that you can uh you can ship uh much faster. Um the other the alternative is to request that ZKVMs adapt uh and provide an interface that is a uh kind of like an OS.

Um then it's pretty nice because you can just dump uh a binary as if it was running on Linux or Mac OS or Windows. Um and it should run it should work. the the disadvantage is that uh it's going to require the ZQVMs to implement more logic because those uh those oss they work with advanced uh hardware features like memory protection and things like this they will need to be implemented that means that you need to have more um more um yeah more support uh more hardware support in the ZKVM so more complexity in the ZKVM um I would say anyway if you look at the way uh if you look at east proof today uh you can see that the average block takes 13 seconds which is way too slow uh the median block is also at 7.8 eight which is not great if you want to have blocks uh a new block time of 6 seconds. Um so I would say anyway there is a need for optimization in the ZKVM itself and uh that's good.

Uh the good news is that there is a lot of room for that. So there's an optimization budget and uh I'm arguing the uh the budget should be spent partially on doing the like implementing an OS interface. But, you know, both uh both approaches have their trade-offs. So, I don't want to um yeah, pretend there's there's one that's obviously better than the other. And then, of course, there's option B prime aka fit square peg into a round hole.

And uh in that one you try to bypass the problem entirely by uh removing like taking a binary that is designed for Linux and hacking bits and pieces of it for uh to make it fit in the ZKVM. Um so we've made some tests for for this. Um it's kind of working but uh I would say it's more uh it's very experimental. This is not what you want to go uh in production with. So it's okay for uh testing, it's okay for optional proofs.

Uh but when you when we get to uh mandatory proof, this is this is not an acceptable solution. So what did we did? What did we do with GU? Uh well, we chose the more conservative approach. We're only going to focus on those uh platforms, those ZKVMs that uh are supporting what we need.

And yes, we're not going to get all the ZKVMs and we're not going to be the fastest, but that's not really the mission of GU. The mission of GU is to be the correct reference implementation of the protocol. Um, and so as long as we achieve this, uh, that's fine by us. So, um, yeah, we're going to to, uh, target WASM. Um, we're going to take to target the the one ZKVM that did the Linux compatibility implementation.

Uh and then we're going to do some experiments with some compiler called Tamago. Um but yeah, it's um it's more experimental at this stage. So um the friendly targets there's Xyron which is a MIPS based implementation and shout out to them because they they've been very uh proactive in uh in implementing the Linux uh kernel interface. Uh one thing I forgot to mention is that Linux itself uh you know can do a lot of things can do multi-threadings can do all those things but it's also been designed to work in embedded targets with no MMU and very little features. So it's actually not that hard to implement a a Linux um like a reasonable Linux u kernel interface.

Uh and they did this and as far as we can tell it works great. Um otherwise we're we're working uh with W wasn't platforms and uh we're going to attempt risk 5. Uh it's a bit harder because the output of the compiler is not exactly uh the one that uh all those ZKVMs expect. So uh there's going to be some tweaks but of course we're going to try. Um so this is where we support right now.

Uh there's SP1. SP1 goes through WOM and then they do some uh risk five like WAM to risk 5 interpretation or sorry transpilation uh they do this for uh for um what's their name uh for arbitrum so um so yeah we're we're we're uh we're profiting from this uh then there's openVM also using WM and via this uh this tool called powder um they they're going to um to uh like we can also run on uh on OpenVM and then uh there's Zisk. So Zisk is a risk 5 uh implementation. So we're going to use a compiler called Tamago uh but it's got some issues. So this is still work in progress.

And finally there's Ziren uh where everything uh works fine for us. So that's that's encouraging at least. And um and yeah, once again uh good job guys. Um right. So what is uh what is um the other things we could do because just using the right platform is only half the half the the path.

Um we're going to have to still uh do some runtime hacks. Um but we're also going to try to do some go uh some things that are valid in Go that will bring uh some speed up. So we're going to change the the allocator using only Go primitives. And we're also going to try other EVMs like EVM1. So, I have some uh some screen captures of PRs that were created.

Um we're we're going to to experiment that and hopefully we we have some announcements to make in the coming weeks. Um yeah, so as a way to to conclude, um it's pretty clear based on this work that the ZKVM ecosystem is still maturing. So, it will uh it will be ready. Um, I think it's uh the deadlines are a bit aggressive to be polite, but uh we can uh we can still um I mean even if we don't make them, it's fine. We can wait maybe another two years and and have the the perfect product.

So that's that's not a that's not a big worry. Uh I would say the biggest the biggest uh point here is that if you look at our support matrix, almost none of them are risk five. So I think uh like the message would be it's uh sorry the message is it would be a big mistake to to do risk five to enshrine risk 5 in uh in Ethereum. There's plenty of other options that make sense. Uh but yeah that's that's the conclusion.

So that's that's all for me. The first flight of laminator discovery and the shuttle