Speedrunning the Design of Ethereum as a ZK-L1 | Elias Tazartes - Kakarot ZK-EVM

[Music] all right what a great talk excited about this next one we have a co-founder of kakarat elas tazartes giving a talk on speedrunning ethereum as a zk1 it's going to be a good one please give it up for elas all right hey guys my name is elas I am one of the co-founders of kakarat and uh we've been working a lot on making etherum provable um Friday we became one of the new beam chain client teams to try and Implement a provable etherum who here has heard of the beam Chain by showan okay not so many so it's the effort made by The Ether Foundation to incorporate more snarks and Starks directly into etherum and why does it matter it matters because in the last few on on in crypto in general we have seen that as a general Community we want more bandwidth and less latency so we want more execution on etherman 1 but we also want more execution on every chain so etherman one today does 30 transaction per second and if you include all the rollups you maybe get to 300 this is still not enough to scale to the next level be it the 4,000 sustained of Solana or even the up to 60k of Visa so we want to grow this and E themm the core value of e themm is not speed it is verifiability uh inclusiveness security and so as as a result you have the system POS and also the current execution layer which assumes small comput and small bandwidth for both the actor that is supposed to propose the block but also the actors that are supposed to reexecute the block verify everything is correct and sign on it and tomorrow with the many efforts that are done in the ZK research you assume that ATT testers now are even less uh have even less computes but that's fine and you assume the proposer has extremely large comput and why you are you allowed to do this is thanks to ZK thanks to ZK you can create this asymmetry between an actor that we call prover that is going to do a lot of work to convince a verifier that something was done correctly and this is extremely convenient for a THM that has already kind of dipped this this his toe into the separation between Builders and proposers that does that ring a bell does that remind you of PBS The Bu proposer Builder separation this is one step further in it's called APS a tester proposal separation for those who want to look into it but it's truly enabled by ZK because with ZK you can unconstraining they can have a huge computer it doesn't hurt verifiability which is the core value of etherum because the the big Builder super computer is going to generate zq proofs certificates of execution for every single block they build all right so what does it look like you have a slot 12 seconds you build the block so you include 100 to 150 maybe 200 transactions in your block be they trades swaps anything you name it games nfts and you broadcast your blog to the peer-to-peer Network and tomorrow instead of broadcasting the block the full block what you're going to broadcast is a proof that the block was executed with integrity and the sufficient data to verify this proof so that means that we have a new frontier for ZK to cross and that Frontier is called realtime proving so I'm sure you guys know who here has heard of the concept of ZK rollup yes so everyone so ZK rollups uh EX create blocks they create zero knowledge proofs of those blocks and they submit those proofs to Ether L1 they're not so constrained by time just yet which means that they have minutes if not hours to generate those proofs so today let's take Stark that example it's a z roll up it takes up to eight hours to settle proofs on etherum of course it's for matters of agregation but that's not the M that's not the question means that today we need to cross a new like kind of 40x in speed in proof generation time to be able to claim that we can make ether as zk1 and for that it means that kind of as engineers and researchers we need to uh really look zoom in into the proof lifetime find every single bottleneck or every single second that we can gain and do it and that's this diagram showing you that as soon as the create the proposer creates a new block you need to pre-process the block to create Prov inputs you need to generate a so-called trace and then you can generate Zer knowledge proof with that Trace so there are essentially three main steps you can add one or two depending on who you are and what you're doing proof wrapping proof conversion but let's focus on O3 and the point of today is to say a block let's you that way you can have the orders of magnitude in your head so a block amounts to let's say in the hundreds of millions of so-called Cycles you can use them as arbitrary unit they're the CPU cycles for ZK VMS so between 250 you can go up to 6 600 million some 1 billion depending on how big the block is and so we use this uh speed measurement Hertz so megahertz is 1 million cycles per second so tldr is you will see in the benchmarks if you look a bit into it the megahertz word come up a lot and the cycle so I just wanted to give you this mental model we are at the 10 of megaherz order of magnitude and a normal CPU that you have in your computer is rather at the order of magnitude of gigahertz so you have this THX that you need to bridge to be at the at the same speed at CPUs but we will we will be fine with 100 MHz for now and until the next years so let's just dive into it and see where time is spent and if you want to follow more closely this this effort uh there's a website called eth proof. org I'll come back to it but this is where all the data on proving etherum is allocate uh aggregated and I have eight minutes okay cool so as I said generate Pro inputs generate Trace generate Stark broadcast Stark I'm using the word stark you might have heard the word snark um there are similar Concepts it's just that everyone is using Stark uh today most people okay so we call it ZK Pig you can call it anything you want but it's a ZK prover input generator and what you do is you essentially take a block and you take the entire state of etherum which is um in the terabytes and of course you can't send that over the wire and try to go to the substrate the minimum the exact minimum state that you need to run this block without having access to a database in real time so what it means is that if my block has 20 transfers from me to all you guys um the prover will need my balance at the beginning of the block and all your balances at the beginning of the block and no one else's so this is what we call the kind of pre-processing because you need to extract extract sorry the absolute minimum needed to execute your block and that goes for the code that you touch the storage that you touch and so on and so forth and there are many tools to do it there's one by uh rezero one by suent I think they are similar one by us um at the end of the day it is something that should not be your problem because it's mostly engineering it's not ZK and so today with a remote R PC we already have a problem we're at two minutes to generate those inputs so the obvious end game which is simply a matter of optimization you need to run this step as you construct the block we already seeing that we're already out of the our 12C deadline so we need to optimize this in the next month or two so okay let's say our slot uh is 12 seconds and we only allow the prover input generation which is just pre-processing to take up to 1 second and ideally you want it to take 0 seconds and today it's 2 minutes if you use a remote RPC to query all of the storage that your block is going to touch and the time that you see is mostly just ping round to Ping because you have to Ping uh remote RPC any time you hit a storage slot all right so let's get to a more interesting part generation Trace so Trace you have to think about it um is my mental model you have to think about it as this big Excel table where every single row is the state of your computer your virtual computer um your the state at every step so first step I am I'm initiating my program Second Step I've done some things and every every row of your Excel sheet you're logging the exact state of your computer and this is going to be useful because the prover is going to do nothing else than check that every single step uh respects the constraints of your the the way your computer is supposed to work so what you want to prove you simply want to prove that a program which is the etherum execution layer specification the evm the etherum smart contract execution engine is operating uh correctly so that it runs on inputs the current state of the world in a block and produces some output and this I think many of you have heard it it is colloquially scientifically named the state transition function so the only thing you need to prove when you're proving ethereum execution is proving that the state transition was done with integrity and this is what validators do every day all the time the only difference is that they do this by re-executing the entire block block after block so every time a new block is produced you expect all of the nodes to re-execute transactions what ZK does is that you now expect people to verify proofs and the main difference is that proofs are exponentially cheaper to verify than every execution so that's it block data ether execution layer in a ZK environment and that gives you a trace and just to give you our lessons learned at kakarat the only the thing we did was uh have a ZK native implementation of the etherum execution layer in Cairo and that gave us um the ability to run blocks in a provable environment which is the km all right so how fast is this and is it to B neck I phon our friends at rero and asked them what is the theoretical Max that you have right now to generate a trace for a chunky block let's say block 21 million and they gave us 5 seconds for that block which is not too bad but maybe a bit problematic for the real time element except except especially sub block and this number is if you have a extremely big CPU but we'll take it and we think that the space is pretty much well Advanced on this um so we have 10 maybe 5 seconds on depending on the Block for Trace generation and if your block is too big you are already out of the game you are above your 12 seconds and that's a big problem so I think the key idea is now people are looking into Trace parallel Trace dation I guess parallelization is the obvious answer that most people throw at many problems in engineering and that's what uh we are doing and most teams are doing the only the other thing you can do is break a block into chunks but that also gives you horis paralyzation okay so now generating a star so as I said you have this Trace which is a big Excel sheet and then you have a star prover so I have this very high level very dumb down version of a prover disclaimer I'm not a cryptographer myself I'm a Zer knowledge engineer but uh this is how I view a trace simply that every Row in your in your yeah every Row in in your in your table is a state of the of the CPU at this particular moment and what you're going to apply on it is mathem polinomial constraints this is really I think this help me unlock kind of a better understanding when when the words traces or Starks are thrown out so this is now how I see it in my in my non-cryptographic brain and so this is very simple you feed to your provable computer the evm specification so the way you expect evm to work you feed it the inputs and then you generate a star and the goal is that this star is extremely portable you can send it around and for those who have been to some Celesta events this is what unlocks proof-based interrupt if you've been to some sucin events this is what unlocks uh verifiable servers this is at the heart of everything we do which is verifiable Computing I think that's that's pretty cool that we're building towards including it directly in the core of ether L1 not just rollups okay so today if you go on eth proof. org which is the website in which uh where all the provs 163 us narfi zkm many others are posting proof proofs of eum L1 blocks you will see that the average time is in the 2 minutes so that's already a problem um if you are um stacking a lot of gpus together you can go down to maybe 30 seconds but that is very costly so I think there's a double challenge which is how can we go to 5 seconds for this and how can we make it not too expensive so you ideally don't want to put many gpus together if they're too expensive uh okay so that's it I again you need to heavily paralyze aover and I will maybe not talk about it but hint at it there are many teams working on Hardware acceleration it seems like a buzzword but at the end of it it's just lots of cool gpus Engineers that try to write libraries for provs on the GPU and the other thing is some lowlevel optimization like how can you transfer data from the GPU and CPU fast and even create new kind of chips which I think what fabric is doing with the vpu okay when once you have it you just have to propagate it uh if you're L1 to ATT testers if you're roll up to aggregation layers or just L1 that might be a problem though cuz the proof is several megabytes maybe one or two if it's a star so there are tricks to make it uh faster uh sorry lighter but that's not the Croc of today so that's it um we need we need to get this in Under 12 seconds I think you can expect by end of year even before that teams are going to be able to do it and I'm I this is what we're working on every day our team 10 people mathematicians and engineers in Paris and the goal is to prove any blockchain so that's it thank you so much