What to Expect from ZkClients - Guillaume Ballet - Stateless Consensus

Transcript

Um, real time proving is here. Who has heard that? Can you can I get a show of hands? Okay. And who believes that in their little heart? Wow. Okay. Three people just for your information. Um, no, I mean it's it's true there's like proving performance has increased. uh it's getting realistic to build at least prototypes using it. Um but as client developers as you know infrastructure providers like service providers we have this is the the right time to start asking a lot of questions um in order to to figure out how do we

make this thing work and I have to warn you a bit in advance. I've had a lot of conversations this week. So there's probably going to be a tinge of pessimism in this uh in this presentation. Uh but the goal of this presentation is not to to be an essayer at all even though I will definitely sound like this at at times. Uh but to really bring up the questions so that we can uh start having the right conversations. Quick reminder, I mean I assume everybody knows here how does a client uh work at the core? I mean, of course, there's a lot of heavy machinery around this, but we receive a block, we receive the state, we run the state transition

function through the EVM, we get a post state. Now, we introduce EKVMs and there's a lot of uh mathematical mumbo jumbo that uh that scares people off, but the the principle is very uh simple. uh you have an input, you have an output and you have the ZKVM that will do whatever it takes to prove that if you feed it a program with this input and this out uh and this output, the input indeed corresponds to the output when running the program. So everything is is validated and this is quite interesting for validating roles at least because uh as we will expand uh it allows like it brings a lot of advantages and it also

uh brings a lot of complications for anybody who's not um a validator. Um so this is what the new diagram uh happens to be in ZKVM world. Uh I made some design decisions. You could argue that you don't really need to run the same old thing before, but uh yeah, this is the the choice I've made for the the sake of simplicity. So it's basically the same uh the same principle here except you on top of that you add like as an output to the to the block uh creation or validation uh transition function you uh output a witness that corresponds to the pre-state that is

going to be used during the execution of ZKVM and then you run in the prover a zkVM which is typically emulating specific architecture can be MIPS can be risk file This is the the most popular at the moment. Can be others if you've heard of LINVM. Um and then on top of that the program that that it emulates the risk 5 program it emulates is the AV EVM compiled as the target architecture risk 5 MYIPS uh you name it and then on top of that the EVM itself is emulating the the contract and the output of this is a lot of traces and then it's fed into some polomial magic uh and you also take the the post state to make sure

that like I that the input and the output match and you get a proof. Um so it's a bit more complicated but not that much. Um so when you are uh a validator it's great right you don't need to reexecute you have the proof that the execution did exactly what you expected it so you can just take the new block you can take the post state route and you say this is the new post state route this is this block is valid I can accept it I don't need to store any state I don't need to store uh I mean maybe I need to store the blocks but not um not as much either because I know from uh I can just keep

the the header chain basically it's great I don't need to to sync sync is a pain uh I can create as many nodes as I want if I want to start doing DVT or things like this um you know like load balancing whatever I can do this um if you you people might remember this uh this post by uh Peter Silagi around the last dev connect which was about uh I think he called it true client diversity where a client would produce a witness to be able to re-execute uh that uh that block and then you could verify like you have a main uh a main client

which at the time would uh was guest maybe today would be another mine and then you would take that um that block that witness and re-execute with the stateless client version of guest of rest of whatever. Uh so you could do very very simply and very cheaply you could do um client diversity inside your own machine. It's the same thing you could do that. Um you could also have prover diversity. All you need to do is have several provers and indeed we want we want to have that because we want to be able to make uh because producing proofs is very expensive. We want to make sure that if one prover defects, we have backup plans. Um, and then I'm

going to skip the KO van because uh I don't has have as much time as I thought. Now, that was the the benefit. Let's go over the doom and gloom. Uh, this is great for replayable blocks, but that means and that was a fear that predates the ZKVM. If most nodes on the network are validators and if those validators do not keep the state, who's going to provide the state? Big question because if you don't have the state, you can't sync. If you can't sync, you can't have new joiners?

That's um yeah, that's that's a problem. Um and on top of that if we want to implement other scalability tricks like state expiry not only do do you not find the state anywhere but even uh the state that is available is not the complete state bit of a problem. Um, and incidentally, uh, at least in the models I've seen, the block producer is also the prover, which means that, uh, you like the this is the end of homestaking.

It costs quite a lot of money to produce a block. If you're a homestaker, you're not going to have that. You don't have a 10 kilowatt power line. You don't have 16 uh 16 GPUs at home. um or or you're the hell of a gamer. Good for you. But um yeah, that's that's not realistic. Um yeah, so these there's this uh website, I should have given the link, sorry for that. Uh eastroof.org that produces the some numbers. So they're they're not, you know, they're not lying about it. They're just being realistic.

And those numbers are actually a lot better than they used to be even six months ago. But you can see that the latency uh is an average of 49 seconds for producing a proof and the median is 7.6. This is where the real-time proving is uh like comes from 7.6. That means after producing a block you have you can fit most blocks the proof of most block inside um inside the 8 seconds that that you have left.

Um, but it's slow. It's expensive. If you take this number, that's 50K a year. And by the way, I'm not exactly sure where this comes from. I I suspect it's more expensive, but that's just my my opinion here. Um, but yeah, 50K a year. And that's with the number the actual numbers that means a block gas limit around I mean if you look at most blocks on uh uh on ether scan or scan of course um that's uh you know they're around 30 million uh so what if you crank the the gas limit to 60 million um so yeah this is to explain the problem a bit more I'm going to do a bit

of walking here so the the green like this is a slot Right? You got 4 seconds. Four four seconds for block produ production, 4 seconds for propagation and attestation and four uh seconds to relax. Now in the new model, you still have 4 seconds for block production because you know uh builders still want to provide the the best block they can. They can play their timing games. They can do everything. And then you have the proving that starts and three weeks later you do have the propagation plus plus attestation which is very small right. Uh and the good news uh the good news about this is that if you run uh this verification it

doesn't matter how many transactions you had in the block. This is pretty much the same time which is where the scaling come from. Because if you go back to 1985 when you produce that block, you could double or triple or quadruple the amount of uh transactions you put in that block. The time you verify to the time to verify is exactly the same. Um and one uh last thing I wanted to uh talk about is uh the what uh called the conjectured uh sorry there's there's a lot of conjectures in that thing. So even the mathematical foundation of that thing are a bit shaky uh because the whole uh all those numbers uh from what I understand could

be wrong prove me wrong please uh if I am and uh those were assuming that there was a conjecture I think it's called the proximity uh gap right conjecture thank you um it got disproven so we don't exactly know how much more uh how much slower it needs to be but if we want to maintain the security the proving is actually actually needs to to slow down. So once again, this is not a terminal thing. Uh we just need to make everything faster and it's happening. No worries about that. Uh but yeah, it's still I mean at least I feel that there's still a lot of work ahead of us.

Um how much time do I have? I think uh >> okay, thank you. So um I'm listing all the problems. I promise there's a happy handing. Um there's um there's the sync. Uh so of course this is not uh the arrogant style sync. It's more like the snap sync of GU. But the idea is that you have a boot node and you have nodes over the network and in theory you just connect to every node on the network and you get a bit of data from everybody uh kumbaya you get your uh you get your node synced. In reality, it's not so uh even some nodes uh like the boot nodes are the ones that really get hammered.

And in this future potential dystopian future, this gets even worse because the the request to sync becomes so uh heavy that the boot nodes dies and no one wants to run one because it's just too expensive. And then there are people storing the state privately but given the fact they don't want to become like a regular boot node they just serve their friends and that's it. Uh and then well uh if you want to become a competing operator like if this node starts misbehaving like let's say it's a producer he starts be misbehaving well um you can uh either start your own uh gaming rig or you uh just have to accept whatever change they want to force on

you. So that's the the question who has the state right? uh if it's if it's uh like this is a centralized centralization pressure that we we need to take seriously and start considering uh so because if the state becomes more centralized like I said you have potential extortion permanent loss those people can actually lose the data uh censorship they can decide well uh I'm not going to serve you that state and yeah that's nice this little fossil protocol you've got but once again I won't be building blocks for it so if you want to have it. Good luck.

So, um, we started thinking and my team started thinking, uh, about this. Uh, I have this link to Carlos's article about oopsie. Uh, I, uh, I'm trying to remember because initially that meant something else, but it's optin opt-in ownership of partial state state of interest exclusively. Yes, that's uh that's a bit convoluted, but that's exactly what it means. people uh have uh only part of the state and uh they they share it via v via snapsync. So this is uh this is one avenue we're exploring to to achieve this. Um and uh the last problem I want to talk about is proving the state. I mean it's very uh connected

to to the other to the other one. Uh but um the execution proof provided by ZK it's not the silver bullet. Sometimes you do want to have the state and you do want to have the uh the proof that it belongs to this state route. Uh and there's a lot of applications that come to mind like wallets. Wallets are not going to uh they have no need for a uh for an execution uh for an execution execution proof. They just want to know that this user's wallet is indeed in the state and having this value. Uh DABs, RPC, everybody. Uh and of course sync uh all those things they actually need good old MPT proofs. Um and so what uh is to be taken uh out of this slide if if you

are an RPC provider uh please or even a DAP or a wallet please please please stop trusting prove everything you send on the network. Um and then let's be uh like the risk is that the burden of uh state providers will increase because proofs are expensive to generate. Um but we do have mitigations and here it is a shameless plug because most of these EIPs are from my team. Uh but uh yeah the the first one is code chunking because the proofs are large uh owing to um to um the the chunk size the sorry the code size. So that's mitigates this

problem. It removes some provers. Uh so the three weeks like uh I was talking about um the state tree change we could switch to a binary tree that makes the proof uh smaller. Uh there's EPBS which is slated for glamm. So very good uh meaning like it's less of a problem if the the proof the proving lasts uh you know fills the whole slot. And then there's there's this link by by rig uh rainbow staking uh which I'd like to uh to expand on because I think it becomes very uh very uh relevant right now and the idea is to uh is to reward people serving the state to make sure the state does not disappear. Um so

unfortunately we lost a portal network but that's uh I would say that's okay in the sense that they did not have a an incentivized way of proving the state at least they they didn't have it at at the time of their uh demise but uh but yeah we need something like that and uh maybe we can think of uh EL sync committees uh we can of course like those hearts once again shameless plug uh oopsie state expiry this is what we're working on and repricings. We're working on that with with rig. Uh repricing being trying to slow down the growth of the state to make sure we uh don't fall off the cliff just uh like too quickly. Uh ah okay, missing the last slide. Um or oh okay,

no. Um there's a QR code I'd like to show, but uh Oh, okay. Why not? Um, so we're going to uh like like I said, the goal was to ask questions. We want to uh not just ask the questions, but try to answer them. So, we're going to run a stateless summit at HCC in K next year. Come. It's uh not going to be as expensive as last year, and uh it's uh going to be uh uh a lot of fun. K is a very nice place. Uh some of those French people are actually nice and uh uh so if you want to register or if you want to have more information this is the QR code and please uh come help us solve the those problems. THANKS.

Excellent presentation there. A little bit of a speedrun through it and that actually left some time for some questions here, believe it or not. So let's uh if we could bring up uh the questions here. Uh let me ask the first one while it loads here. Uh what can we expect to see from ZK proving in 2026? >> Um nice demos. Honestly that's uh I mean um okay that's my opinion once again but uh I think we're not anywhere close to a to a production ready um system. So you will get very impressive demos which is nice.

Uh but I don't I don't expect much more. >> Okay. Um and then uh let me ask the next one here. Uh how will home validators running uh ZK EVM ensure censorship resistance or participate in Fossil without execution state or mempoles? >> Yeah. Um that's a problem. That's uh yeah stickless summit come. But uh yeah uh it's going to be difficult to to achieve for sure. >> Okay. And let me see if I could slip this last one in here. Uh similar to proposer builder separation. Uh what's your take on having proposer prover separation?

>> Uh great idea but uh in my view impossible to implement. Okay not impossible but uh then comes the question if it costs 50k a year to produce a proof you need to incentivize those people. I'm not sp I mean I like you guys but I'm not going to spend 50k a year just to provide you a proof for free. So we need to create some incentive make the design some incentive mechanism in the protocol. They don't exist at this time. >> Excellent. Excellent. Please another round of applause for Jum.