EPF6 Office Hours | Kev

Okay, awesome. So, yeah, welcome everyone once again for the officeovers in the EPF Gh 4. Um, it's one of our last office hours uh with guests with AMAs. Uh, there will be maybe one more after this. Uh, but uh for uh couple of last ones, we have uh more special guests and today our invitation was accepted by Kev.

Uh, thanks so much for joining us today. Of course, it's an honor. Um, so um, uh, Kev, uh, you might be familiar with his work. He's now, uh, the leader of the ZK EVM research team in Ethereum foundation. Uh, but, um, uh, we would like, uh, to get to know you, Kev, like what, uh, what is your background and, uh, uh, learn some context about you before we jump into the in into the present.

And uh uh if you don't mind sharing some of your um some of your journey, how you started with uh Ethereum protocol, what brought you uh to the ecosystem to the core work and uh yeah, what was were your first contributions?

Uh yeah, thanks. Uh yeah, thanks for having me on as well. Um it's great to meet all of you and it's great to see you again, Mario. Uh yeah, where did I start? Uh it's probably been about 5 years since I joined the Ethereum uhish community.

Um probably about 8 years since being in the blockchain um space around there. Uh I started off by just uh maintaining a Go version of a non-thereum client. Uh just designing a more modular version in Go. Uh then I moved on to more privacy related uh topics uh maintaining a privacy uh client uh and from there uh just naturally if you're doing anything privacy related you sort of move into cryptography just because in order to enable uh these privacy features that people want uh you usually need some sort of cryptography. Uh so my journey started moving more into uh cryp like basically cryptographic or cryptography related problems.

Uh I participated in sort of the Monero community for a while uh while I was moving into uh cryptography related things. Uh and then from cryptography we sort of needed uh this thing called a snark which basically gives you proofs of executions of uh essentially any function. And one problem that I encountered uh while trying to learn these snarks and use them for our use case was that actually writing them was pretty errorprone. Uh so one thing that I started working on was this programming language called noir which allows you to write um your programs in a type safe or nicer language and it will compile uh down to a proof. It's essentially a proof of execution uh using what the snark technology.

Uh and while I was doing this, I think I met up with another researcher called Dankr Feist possibly around 2020, so five years ago. He told me about an interesting problem uh to do with this thing called vercleal or vertical trees. And uh I was pretty interested in sort of what it like the cryptography related there. and uh optimizations that were needed and that was when I started uh sort of working on the Ethereum uh protocol a bit more. Uh yeah, it's been about 5 years and I think it was only last year or maybe two years ago where I started doing more Ethereum related things.

So uh for example, I participated in the trusted setup and the 4844 related uh work. I don't really remember how I got into it. I think possibly Dankrat just said again, you know, this looks pretty hard. And uh it yeah, it looked like an interesting problem. And yeah, as of last year, I officially, I guess, joined the Ephreium Foundation full-time and started working on the ZKVM um related work.

Awesome. Okay. Yeah, thank you so much for sharing all of that, uh Kev. Yeah, it's very interesting. It's very cool background.

We had Tony uh recently as well and I feel like similar patterns also based on the privacy monero and that's really based and uh and also uh I mean you've been um uh I know so you mentioned the privacy tech and so I'm curious like what do you what do you work on uh these days? How do you how do you see uh your experience reflecting there? like I know that you've been contributing or building the no language for example that's really cool and um what lessons like this ZK privacy uh realm uh gave you that you now uh uh apply in the in the Ethereum in ZKVM uh yeah what is it like working on on the research today

um yeah I guess it's a bit of a misnomer that it's called ZKVM um unfortunately but yeah we're we're here and we can't change it. Um, I definitely say the one lesson I've learned from all of the privacy related things is to try to keep it as simple as possible. Um, once you try to do anything privacy related because all of the proofs are created on like the client side or by the user, you need very good performance and very good performance means cutting edge cryptography. uh but over the years I've introduced quite a lot of uh bugs and found quite a lot of bugs just due to this performance threshold that we need to meet. Uh so with the ZKVM uh related work that I'm working on now, one thing that I'm really overindexing on is how do we make this as simple as possible.

Uh performance is great but I think a bug is just catastrophic. I mean even in the private in the privacy sort of uh sec uh domain it's even worse because you could have a bug and no one even knows that there's a bug there. uh someone could essentially just take out a salary from uh like the money that's been deposited and you wouldn't know because well this is one of the features of it being uh privacy related. Uh so yeah, I definitely say trying to make things as simple as possible is the biggest takeaway that I've gotten from working on privacy tech for a while.

Yeah, that's a great lesson. Thank you so much, Kev. Awesome. very well. Um yeah and um so another question about the present is like how do you so now you are a leader of the the team so I'm wondering like how your responsibilities change and also like with the recent uh maybe more focus towards uh the lean future and and uh uh yeah different approach like the more more into future like what how do you how do you how do you see the future what are you what are you building towards what is it uh what is it like today leading a team and and trying to figure this out.

Um yeah.

Um yeah, I guess leading a team is not completely new. Um in my previous experiences, I think I've mainly only led teams uh just a virtue of being super early and or just uh being there long enough to know like how the tech works. Uh so definitely leading a team is not super new. I think leading a team in the Ethereum foundation is definitely a bit different than um sort of at a regular startup uh just because the stakeholders uh in for Ethereum are usually pretty external and pretty vocal about what they want. Uh so you can't just sort of make a unanimous decision as you can with a startup or uh when you're leading a team.

Um, so I say yeah that's definitely a new thing that takes a bit of time to get used to I think and uh navigate. Uh, with respect to the lean stuff, yeah, I I always try to keep an open mind about how things are going. Uh, lean is a very big vision. I think the lean EL is where the ZKVM stuff uh, fits in. And there's also lean CL and there's lean data.

Uh I would uh yeah I don't I don't think I formed a full opinion on all of the lean related things and this is not sort of a property of lean. It's more of uh when things are too far out. I I usually don't try to form too much of an opinion on it. Uh I have I have like directions that I think we should follow, but in general forming opinions on things that are too far out I usually get them wrong. So yeah,

awesome. Yeah, that's that's an interesting insight. Uh yeah. Yeah, maybe it's it's hard being opinionated in uh any to be fair. Uh there is especially especially the research.

Yeah, thanks so much Kev. Um yeah so I mean um we always start with this little fireside chat but I want to invite everyone to um uh to give us a question to to ask have anything about his work about uh his past present or future uh I believe there are some fellows who are working on related things that are familiar with your work so please raise your hand and also take the opportunity to ask some questions um so it's uh not just me here uh we get we got uh 19 people here today. So, hope we get some get some questions of you guys. Anyone? Okay, Shane.

Yeah, go ahead.

Hey, Kev. I think on Twitter you had one point put out a post on um how like the minimum hardware requirements to run in Ethereum node are. I'm curious how you think that could potentially change with uh CK.

Uh yeah, that's a good question. Um so just as a reference, the minimum hardware requirements or the hardware requirement EIP which I believe is like 7870 uh defined three different nodes. So one being a full node, one being a validator and then the validator node was sort of split up into like local block builder or block builder. Um once we introduce ZK we sort of we so first of all we add this new type of node called approver. Uh technically you could put them under the builder because if you build a block in order for it to be accepted you need the proofs to be attached.

Uh so we may not need to introduce another entity. uh but if we do then the entity will need a lot uh more powerful hardware requirements because creating a proof within like 10 seconds or whatever you need at least GPUs I can't say the exact number but it's going to be somewhere in the range of 16 maybe 32 for one proof and because we need this uh notion of like uh prover diversity because you can't just have one proof what if that zkVM is like buggy they're all sort of complex uh so what happens is that you have multiple proofs just like how you have multiple clients. Uh so the the prover basically the the 32 number that I said for 32 GPUs you need to multiply that by whatever the uh redundancy factor you need is uh it's unclear what this 32 number is or what the number is. So this entity will definitely need to be a lot more sophisticated or at least a lot more powerful. On the other hand, the validator that uh I don't have the EIP up, but uh the validator requirements drop significantly uh because in order to execute a block uh instead of well in order to validate a block instead of executing or re-executing you just download a proof and downloading a proof is about 40 to 100 milliseconds.

Um the good thing about this as well is that it smooths out the worst cases. Like if a validator currently receives a block that's really hard to execute, they're going to need more powerful hardware or at least it's going to take a longer time to execute. But verifying the proof is sort of constant regardless of how hard the block is. The the asymmetry as you as I sort of previously noted is in the prover. The prover will need to do more work.

Uh so yeah this is how uh the hardware requirements will roughly change uh in terms of uh what the current landscape looks like. Uh the proofs themselves are a bit at least the the numbers we're looking at right now the proofs are a bit heavier in that we're looking at numbers in terms of like 300 kilobytes which is a lot but I think we can uh do this other technique. I believe pis has a EIP or E research pro on RLNC on how to sort of uh have a more efficient way of transferring data over over the P2P layer even if the data is actually big by essentially chunking uh the data up. Um does does that answer your question Shane? Yeah.

And um I was also curious if uh you know if you guys are looking at how as the approver then would that work with sixcond slots if you have you know less time to actually produce that uh it seems like from the validation perspective you'll have you'll need way less time I guess for the prover need to be able to get it out within like a couple seconds or something.

Uh right. Exactly. Um so with this sixcond slots uh I believe there's this an implicit assumption that if you lower the slots time you also need to lower the gas limit as well. Um so the prover should be doing less work but saying that there is an inher inherent overhead for creating a proof. So even an empty block is not going to take you zero seconds.

Um I can't remember what the number is from the top of my head. It might be one if I remember correctly. Um but yeah, once you decrease the slot time, you will need to decrease the the the gas limit as well which Yeah.

Gotcha. Gotcha.

Okay. Thank you. Um yeah I think it's very interesting trade-off that we are doing in this future where like right now the if you zoom out like the requirements for the verifier like the builder and and the validating node are almost the same right if you zoom out with this it's so diametrically different it's super easy to uh to uh verify but hard to prove right so um so it's an interesting trade-off there uh but um I'm also Uh so so what what I'm curious about actually uh when when you mentioned the EIP for the hardware just a quick question related to that about the hardware recommendations do you think it should update with the beard now uh with super nodes uh because uh when I last time talked to pandops they said like it should be similar ballpark but uh now that I saw some uh some latest reports from devets I'm not so sure about that like what do you think have you been following that as well

um sorry um yeah I think it should probably include super nodes. Um I believe to become a super node it was you needed to be staking 4,96 ETH. Um which means that yeah your your bandwidth requirements will go up uh just because you're with 4,96 E you're custodine or you're in charge of more data. It's not just the original data in PRAS. There's this sort of technique where you have your original blob data and then you sort of double it for redundancy and the super node is uh sort of in charge of all of this the data plus the doubling or the extended data.

Uh so there is a doubling of the bandwidth required at least for upload because when I say that you're custo means that you're also in charge of like sending it out to peers uh that require this data as well. Uh so yeah, I think the requirements should somehow put this into or the the hardware EIP should somehow like include this. Yeah.

Yeah. Cool. I was just just a thought about the the EAP because even like the local blog builder uh there has like high RAM and space requirements or like bandwidth.

Uh technically could fit even the super node. Um, but I'm just, you know, I'm just doing I'm just uh doing a filler here, waiting for more hands to raise and ask questions. So, uh, guys, please uh yeah, use the opportunity. Don't let me I think Demetrius was first.

Yeah. Hi. Um how you guys like related to your to the previous question like um these estimates that you gave uh about like producing a proof um where it um did you take into account like the current status of like uh ZK proofs or like are we talking about 16 to 32 GPUs uh in like five years from now where everything is made much much faster and all that like are you taking optimizations on the ZK proofs into account to make this estimate. And uh the second question that I have is that for you mentioned noir at some point and I was just wondering I mean what are the current tools that we can use in order to minimize bugs in in writing code for uh ZK proofs.

Mhm. Uh yeah. So I'll take your first question. uh the 16 to 32. This is uh I would take it as an a realistic aspirational goal is the best way to put it.

I say that just because I haven't actually benchmarked it myself. I mean I've seen uh ZKVM teams or newer ones coming out with these numbers. Uh but the numbers that we have personally benchmarked haven't been I think they're around the 32 to 48 number. Uh this what we're actually proving is a ref uh it's a program in ref called ref stateless. If you look at the ref um upstream branch, it's called ref stateless with one modification to the MPT part uh for the state proof.

Some of the ZKVM teams have this new uh optimization called subblocks. Um I don't know if you want me to get into the details of that uh but essentially it's not been upstreamed. So I'm not taking it as a a given for the optimization but subblocks are similar in spirit to bals essentially but as I said I haven't benchmarked this so I don't want to um uh say like guesstimate any numbers there because I I don't know what's going to come out of it. Um on your second question yeah writing zk p about bugs is pretty hard. Uh I think one direction that the EF is uh mostly interested in is formal verification.

I don't know enough about it to say whether it will stop most bugs. The bugs that I've seen that formal verification haven't stopped have been related to the formal verification uh specs explicitly excluding that part of the code or something along these lines. Um, so I'd say yeah, formal verification probably is our best bet moving forward. The issue, yeah, I guess one issue with like one thing you can't do is uh like circuits diversity because u if the circuit is different, you get a different proving and verification key. So you're technically proving and verifying something different.

So you can't like do the same thing that we do with like client diversity unfortunately. So it's likely that like fuzzing and formal verification are the best tools that we can uh utilize. Um Demetrius does that answer your question?

Yeah. Yeah. Thank you. Um

if you just on the first question if you just u can provide the references that you mentioned about what exactly are you proving and where is this upstream?

Mhm. Yeah. Yeah. can definitely provide the links as and also like how we're benchmarking and uh the abstractions we're using.

Yeah, that's great. Thanks.

Cool.

Awesome. Yeah, thank you Kev. Um Lee, go ahead.

Yeah, I was wondering I was thinking you want to continue the question before, so yeah, I didn't raise the hand. Uh yeah. Uh uh can can you simply send the uh link to Mario so that uh he can share on discord otherwise uh I think the chat here has some issues sometimes. Yeah, we have uh the discord channel. I can take you there, Kev.

So, we can have also photo to post anything there. It's in the

Yeah.

And also happy to say see you again since like

Yeah. Many months ago and you didn't join the RWC, right? So, I didn't see you there. Um

uh yeah, by the way, my question is about like uh uh following the previous question. uh because uh like formal methods you always need to model the system and uh or it's either proof system or the which machine system and this model may have some issues. So that's usually the biggest challenge for the for methods itself and also uh I actually I want to learn more about your current work because I know your previous work I want to learn like since you moved to like the K the KVM what are you're doing now and uh also what's a challenge now.

Mhm. Uh yeah so I'll uh address your first point which uh is a good point. Uh so with the formal verification methods uh one way to think of how it works is that um like yeah so let's say that you wanted to like have some number that said if a car crashed and the person was in there like there's like a 33% uh chance that they would survive. What you wouldn't want to do is test this out in real life because well, you know, it's yeah, you don't you don't want to be risking people's lives. So, what you can do is uh form a model, some like 3D model and then just like simulate it in in this 3D model in some sort of software.

The issue is that if your 3D model doesn't correctly uh map over to the real world, you could be proving something that's not actually true. Uh so this is what Lee was saying and that the model or your formal verification model needs to accurately represent uh sort of whatever the problem is that you that you wanted to model. And this is not always the case. Like you could you could have a model that's just incorrect and it could be proving stuff that's correct in that model but it just doesn't represent real life or it doesn't represent your circuit or whatever. Um, so yeah, this is definitely true and I don't actually know how uh the formal verification folks uh are solving this problem.

Uh, yeah, I wouldn't know enough about it to be honest. Um,

I I don't think they have actually. It's kind of like a very old fashion research trick. I see people like spend days and days to think about how to model the things and hopefully it works. Something like that,

right? Um yeah, so that is definitely a problem that I Yeah. Yeah. I don't know enough about it. But um yeah, I guess on my end what I've been working on right now, um I usually move uh quite a lot up this stack.

So currently I'm working on a lighthouse PR and that uh gives us a proof of concept for like what does the endto-end uh system look like. Uh essentially we're modifying the lighthouse client in order to download proofs and uh also propagate them. But the important part is that the client can now download proofs. Whenever it gets an execution payload, it will wait for like five out of 10 of the possible proofs and if they all verify to be correct, then the node will say this is uh this execution payload is correct. uh execution payload is if you if you're not familiar with the nomcher the execution payload is inside of the beacon block but sometimes the execution payload can be called the e block or the execution layer block.

Uh this is the execution layer block is basically the block with all of the things that people usually care about like when people say stuff like uh my solidity contract or smart contracts all of this data is inside of the execution payload. Uh so this is roughly what we're proving. We're like proving that the state transition of an execution payload is uh correct quote unquote. Uh so yeah, I'm working on the CL stuff related to this at the moment. Uh and also just the standards for ZKVM uh just because the that we have multiple ZKVMs and they've done things in multiple different ways and we're trying to like standardize uh sort of the interfaces between like the the the program that's been proven and like what does the ZKVM offer in terms of API.

Uh one issue that we are coming across that's been pretty hard for me to solve. It's like semisocial I guess is this concept of a Linux cysool. Uh essentially if you want to prove a ref program a ref pro ref is written in rust which is a pretty low-level s a low-level language which means that it can it can compile to something that doesn't assume that you have an operating system like Linux or Windows. But for programs like Go or Java orn net which never mind is written in or C uh you can't get rid of this assumption which means that the ZKVM also needs to be aware of this assumption and needs to prove the Linux sys call. Uh there's about 400 to 500 Linux sys calls the last time I checked or something along the it's in the hundreds.

Uh so we can't support all of them and even some of them are pretty complicated like m map which is definitely going to be called somewhere uh it is always is always going to be there and probably clone as well. These are pretty complicated functions in order for a ZKVM to prove execution of um so yeah we're trying to think of how do we yeah how do we solve this problem essentially without sacrificing performance and are there any ways to sort of mitigate it for example GE uh has a there's a different compiler that for Gh called Tamago that we're looking into that essentially allows you to compile Go programs terms of outs this operating system assumption and for C you need to modify this thing called lib C because that's usually where all of the sys calls are are being called from so yeah this is one of the harder problems that we're hoping to solve by the end of the year wow I didn't I I didn't think about this issue before I only think about like the pure like theoretical part of the looks already pretty complex And this one Yeah. Wow. That's crazy problem.

Yeah, it's a bit hard.

Okay. Thanks for sharing that.

Yeah, no worries.

Yeah, thank you. That's that's very interesting. Thank you, Kev. Um, okay. Iran.

Hi, Kev. Hi, everyone. So I have a question related to the latest research on the ZK in terms of like uh what's the major topic going on right now? So for example, what you're currently research on and also the main blockers. So what's blocking this research and why are you like researching specifically this this topic?

So what's the the main focus right now? Um yeah, so this is kind of a harder question to answer just because um there's a lot of things that are being researched. Uh but I can try to list out the major topics. Uh in terms of yeah, so in terms of on the Ethereum layer, we're still researching the notion of prover centralization. Uh as I noted uh I think in the beginning or I think it was Shane who asked the question on the hardware requirements.

Uh the prover now needs to be a pretty heavy machine and Ethereum usually we we do have sort of an assumption on pretty heavy heavy machinery with the builders but I think this is not a default thing that Ethereum wants to uh assume or at least there needs to be a credible fallback at least for the builders. If the builders don't if the sophisticated builders don't build a block, then the local builders will just build the block. It just won't be as um profitable. So, we're really trying to figure out a credible story for the provers. Um if a prover goes offline, then yeah, you you you have livveness issues.

One research area that we're looking into is distributed proving uh which is where the prover where validators can run this like auxiliary software and they can prove like let's say a tenth of a block and this will be pretty easy. I mean you probably still will need a GPU because none of this is like CPU efficient but you probably will only need one uh GPU. So if you think of the numbers that I said before where I said 32 GPUs then it might be possible for you to have 32 validators with one GPU and they uh talk they they sort of communicate together in order to like uh create the proof. Uh so I think this is one of the main Ethereum related uh research positions. Uh there's also the prover incentives um sort of research direction being done by Julian and this is like how do the provers get paid?

Do we just say that the builders the builders just take a bit out of their profit in order to create to create the proofs because the proofs are cheap enough? I I don't have a super strong opinion on this to be honest. So I'm not super sure. Um, so those are the more social issues. On the ZKVM front, we do see that most ZKVMs because we want them to be postquantum safe or postquantum resistant uh most of them rely on uh particular assumptions.

I I believe there's a proximity prize out but I don't remember the website for it. Um, it would be good if we could prove that this assumption was like correct or at least disprove it or whatever. Um, I I believe it might have been multiple assumptions. I haven't actually read uh what that is if I'm honest. Um, so I think those are the two ones that I can think of right now.

Um, if you ask me a more targeted question, I could probably think of more research uh directions. I I just can't think of them off the top of my head. Sorry. That's amazing. No, no, that was exactly the answer I was uh was expecting.

Was just curious to see where the ZK research is uh is going like which direction also because like recently or like maybe not recently but like couple months ago Vitalik was talking about the ver trees. So how to develop like the trees so which type of algorithm to to follow. So I thought it was kind of related and was also super interesting topic. So was researching also on that and I wanted to know like your your take on that.

Right. Uh yeah. So I guess verical trees are related in that um yeah so the thing that ZKVMs prove is a stateless program. Uh because a ZKVM in order for it to prove something like a stateful program that's actually pretty hard because it needs to prove like the database insertions are done correctly and this is like a very hard thing. So what they do prove is like a stateless program and the input to the stateless program is a MPT proof plus the block.

So the MPT proof is used to basically say that and a pre-state route. But let's just say the MPT proof is used to um is used to show that all of the reads that happened inside of the block are correct. So all of the reads correspond to the pre-state route. And the pre-state route is just a summary of the state or a summary of the database that you can make proofs against. Um so if we introduce veral this MPT proof part will change into a vertical proof and you'll be proving that uh the reads done in the block are uh are correct according to a vertical proof instead.

In terms of going the vertical direction, I think it is at odds with this notion of postquantum uh safe just because verle uses this curve called ber bander snatch or well the most important thing is that it uses an elliptic curve and those are not postquantum safe. Uh so there is another EIP called uh I think binary tree or unified binary tree uh that I can send a link to and that is postquantum safe just because it only relies on a hash function but we also haven't chosen what particular hash function we want to use. We were going to go for a Prooseidon based one and the rationale was that uh the lean or the CL will eventually be using Prooseidon. So it'd be good to have one hash function on both layers, but uh from feedback from the L2s and ZK roll-ups, I believe they said that actually it's much better to use something like Ketchuck or Blake because then you're not uh limiting innovation. Uh because this Poseidon hash function is instantiated over some field and proving systems are also instantiated over some field.

So if you want to have efficient Prooseidon uh you you ideally need to be matching the field uh that the Prooseidon is instantiated over and I guess I think one of our feedback was that uh catch and some certain hash functions although they used to be really inefficient in the past they're actually getting pretty efficient. Um, so yeah, my my opin my yeah, I guess my opinion is that we should probably move to binary trees sometime in the future if not to get rid of sort of the edge cases in uh the MPT and removing the RP assumption. And I guess it'd be great if we moved to Catracklake instead of a Prooseidon uh version because that just forces us to pro to use a specific field. Um yeah, does does that answer your vertical related question?

Totally. More than expected. Thank you so much. Was brilliant.

No worries.

Yeah. Thank you so much for diving into that, Kev. That was great. Yeah. Um yeah any more questions thoughts feel free to ask raise your hands yeah oh yeah awesome uh who was first developing

uh hey guys hey my question is related to your recent work with the consensus client and um like pros so like you to throw more light on what the consensus client would look like when we now move when we have this switch um much more technically.

Mhm. Yep. Uh yeah. So I guess to give a slight overview of the current architecture um there you have a con to run an Ethereum node you need a consensus client and a e execution layer client and the consensus client will speak to the execution layer client in let's say three there are three methods or free methods that it will call uh the first one is called get payload and this is if the consensus layer client needs to build a block it will say um can you give me transactions in order to build so that can you give me the execution payload essentially because I need to build a E block. Uh so the EL will basically look inside of its mempool and say okay I'm going to put together all these transactions and here's the block and then the uh consensus layer proposer will just like take the block put it inside of the beacon block and then propose it roughly speaking.

Uh there's also new payload and this basically whenever the CL receives a block it will send the execution payload in the beacon block to the E in order to validate that it's correct. Uh and then the third method is basically something called fork choice update which is if the CL needs to do a reorg uh it tells the E and the E can do a reorg as well. So when we move over to this uh to this zk attester based client first of all the get payload uh method is no longer useful because there is no mempool like the e doesn't have any state. So get payload is just like removed. You have to use me boost unfortunately.

Uh uh the next one is the new payload. So whenever the CL gets a new beacon block, it takes out the execution payload. Instead of sending that to the E to validate that the execution payload is correct, it will say I'm going to listen on uh my go my P2P network for 10 proofs or five proofs or whatever the threshold is that they've supplied. Uh and once I've received like five proofs, I will then say that this execution payload is correct. uh the fork choice update is no longer needed because there is no EL to reorg like the E doesn't have any state.

Uh so the main thing that actually changes is this engine new payload method. Um there's uh yeah I don't know if you have any extra questions about that.

Yeah, just one more like a follow up. So in other words, it's kind of like um the the consensus um chain, the beacon chain now becomes like the the first class chain in this sense. It now holds the true state of of all the chains.

Yeah. So the uh if you're attesting this is correct. Um you you no longer need the EL. You just have a CL like one binary. If you're building a block, you still will need an E.

So if you're like a block builder, you still need to have the E state. Uh so yeah.

Yeah. So last question. Is there any um um economical model that we have right now? Maybe something rough.

Um more like a reward for validators, our testers and um most importantly the block readers, the provers in this case,

right? Uh yes, I think this was related to a previous question. Uh so the validators they don't change uh the incentives for the validators don't change. It's just their hardware requirements are decreased. Uh the block builders the current thinking is that the the the cost of building a proof is going to be low enough that we can just minus it off of the profits that they're going to get from uh building the block.

and they're already incentivized to build to like make sure the block is like valid by including proofs. Uh so this is okay. Uh we do have a EIP called AD25 which is optional execution proofs which allows us to sort of roll this out and experiment with things in this model. The block builder has no incentive to create proofs because the block is valid without the proofs because it's optional. Uh and what we're what we're planning to do is that the EF or uh a couple maybe uh provers will just run these nodes and just create the proof sort of altruistically.

Uh this is only while they're optional because yeah there's no incentives.

Great. Thank you.

Yep. Cool.

Awesome. Um yeah, thank you K. Uh Ditri. Yeah, go ahead.

Mhm.

Yeah. Um, so I'm I'm just curious. So at the beginning you mentioned that uh especially when developing cryptography we should keep things as simple as possible and I was wondering like uh how feasible is this in case you have this like distributed provers where I don't know you have 10 machines doing proving maybe with different uh ZKVM each one and then you also have the networking. How doesn't that complicate things a lot?

Mhm. Uh yes sir, it definitely does and it's yeah it's still unclear how we're going to make this simple. Uh technically speaking usually you already have something like distributed proving already like when you create a proof uh you can think of it as there's a sequence of byte codes. It's not really this but let's just say there's a sequence of bite codes. The bite codes get chunked up.

let's say every after every 10 byt codes and that chunk gets sent to a GPU. So there's already this sort of communication or orchestration that needs to happen. The distributed proving essentially just instead of having it be intra meaning just the GPUs are just next to each other and you just need them to commun you just need like orchestrator to like send them data. It's sort of over the internet essentially. Uh so my hope is that it's not super complicated but I haven't actually implemented it.

So I can't say what uh sort of like how complicated it might get but I definitely agree that this is this could increase the complexity. It definitely won't be done over the normal like validator network. It will have to be like a separate network uh just for like distributing proofs. Uh and there's yeah as you said there's also the complexity of that it's not just one proof which is what the current ZKVMs are doing like they only care about creating their own proof and chopping it up into like uh subsections in order to send to different GPUs. We actually need n proofs uh which yeah does also increase the complexity.

Um yeah

I see I see. Thanks. And with this like second network that we need to build, uh will like areas of the planet that we that have very low bandwidth be affected and maybe get excluded from the network because they cannot do all all of these things at once.

Um yeah, so this is a possibility. I think it's probably okay because we want this distributed proving or decentralized proving or whatever people call it. Those are two different words. Uh I know people call them the same thing sometimes. Uh we we want this as like a fallback strategy.

Um so it possibly won't be the main thing similar to how currently most blocks are built by uh using mev boost but there is sort of a credible fallback strategy in case things don't go to plan. Uh the the downside of this is that also the fallback strategy will likely be slower than the using the normal strategy and yeah I haven't thought enough about what that means in terms of um yeah how the network would work and if the if if it's slower proving we might just have to keep we might just have to benchmark how much it costs to do distributed proving and always have that extra bandwidth. Anyways, so that would lead back to I think it might have been Shane's question about reducing the slot time. It might be possible to create proofs using uh a proven network or using a sophisticated prover in two seconds, but if distributed proving takes 4 seconds, then we might want to always say, you know, it's going to take 4 seconds. Um, yeah,

I understand. Yeah, thank thanks a lot. And last question, sorry. You also I looked on your GitHub and you also mentioned that you have an interest in number theory.

Do you mean abstractly or just around number theory related to what you do on day-to-day work?

Yeah, I think it's mostly number theory as it relates to cryptography nowadays. Uh but I do have a lot of number theory books that I like to just read and answer the questions like uh like pretend I'm a university student sometimes.

I see. I see. Okay. Thanks.

Mhm.

Yeah, that's awesome. Yeah, thanks Kev. Yeah, I learned that like reading actual math book if you are not in school makes me uh want to learn it more than when I was. So if you have any any good math book recommendations, please also share those. Uh but um yeah, for now Ali has another question.

Uh yes. uh uh I also think about uh the uh distributed uh proven before and uh I'm wondering like communication the latency of the communication would be a major bottleneck or not I mean proof scale and the proof system we can try to make some like uh like optimization or other ways but the communication portal in general is is something we cannot do much about that, right?

Mhm.

Um, and another question is about I noticed uh uh you just released the new internship for 2026 summer and I'm wondering if you have any tips for the application preparation.

Mhm.

Yeah. Uh yes, I'll answer the first question. Um I have been looking into Zisk's model which essentially trades off communication for more computation. Uh so instead of sending um let's say one megabyte of data you send like let's say 100 kilobytes of data but once you send it over the prover or the person that you send it over to needs to do more work than if you had sent over the full 1 megabyte. Um so I think that model looks pretty promising.

I can't remember how much data it exactly sends with ZISK. Um, but it did seem pretty minimal. Uh, so yeah, if we go with this approach, we would probably want to optimize for bandwidth. And it may be that we need two GPUs instead of one or something along these lines. Uh, but yeah, as I said, I haven't looked into this in enough detail to sort of uh say anything concrete right now.

Uh in terms of the internship um yeah I guess on my part I am looking more at least I think I've yeah I should have applied to it. I'm looking more for uh general software engineering skills. I'm un it's unclear to me but I'm I I can be super convinced uh that we need to look into anything that's really lowlevel cryptography like the circuits for the risk 5 ZKVM it's unclear if we need someone to look into it uh but I can definitely be convinced uh I I would say I would be over optim overindexing on engineering skills uh but in general when it comes to these uh EPF F sorry not EPF. Uh I I forget what the what the internship program is called for us. Uh but in general I would say that if someone is good there's usually something to do.

Uh

okay. Okay. Thanks a lot.

Oh cool. You're welcome.

Yeah. Awesome. Uh we got five minutes left. Uh if we have any last question, something cool to finish it with, feel free to raise your hands still. Um one quick thing maybe I was curious about is the um partial proving or a distributed prover because the last time I saw a discussion about this like I was I was told that it's not really possible like it's not efficient or so.

So so I'm curious if you have can share also any resources or any current research on that. would be really cool to just you know you turn up the GTA and you switch to proving and you can run it from your gaming PC just like one GPU be really nice. Uh so used to do that in in the proof work mining so uh that would be really nice. Uh I believe there was an article out there by Jordi on ETH research but uh distributed proving I can't remember what it was called. Uh there was a E research post uh by Jordi from ZISK but I can't

find it at the moment.

It's all right. I will look into it and feel free to share uh share something if you have uh if you have uh any resources later. I think during our fellowship channel in the R&D you are I'm sure you're there. So

yeah.

Yeah. Yeah. I do look inside of the GitHub channel uh for the EPF. I think I saw maybe it was Remy. I might be saying your name wrong.

Ry or Remy. I think I saw some lean related stuff there. It'd be good to know what's happening over there. I at least uh the lean CL side of things. Yes, we have a couple of fellows working on on lane related projects.

Um I mean and sub working together. Uh there is uh there are contributions to reim um and uh and some people here working on the zk provers. So um just left uh um anyway if anyone wants to share their ask something or share their work maybe on on some related stuff. Um last few minutes so feel please use it for some last question folks. We get a bunch of people here.

Mhm. Um, hey Kev. Um, is there a way to like simulate uh distributed proving? Maybe to measure network latency or like in general to measure the efficacy of um distributed proving. Uh yeah, I think we can definitely um simulate it in the same way that we simulate like the networking layer.

uh just by giving the parameters of like what is the latency for creating for creating the mini proof or the chunk of the proof and how big the proof is and then you can put in parameters for like upload and download speed and you should be able to like simulate how long does it take to like generate and propagate these chunks of proofs. Um, you you might need a central you might need like someone that collects all the proofs or else you sort of get pretty bad asymptotics where you need to send a chunk to like everybody. Uh, yeah, I'm not sure. Yeah. So, there's there's like multiple models here that that you could uh go with.

Probably just using a central person, maybe the proposer, and you send the proposer everything or something like this would work. Yeah. Okay, cool. Thanks, Rahul. Um, it's great.

Heavy here. Um, okay. If there are no more questions, we'll have one last quick one. Kev, uh, if you have any other advice, if you have any last thought you want to share, um, maybe some something that you wish you knew earlier in your Ethereum career, um, something to share, some advice to share with the fellows.

Um, yeah, I guess one advice is to maybe just do stuff and uh, things usually happen. Uh, don't be shy to ask questions and uh, yeah, try to just do as much as possible. Yeah, that's awesome. Yeah, and yeah, that's solid advice. Thank you so much, Kevin.

Yeah, that's great.

Um, definitely that's that's what a fellowship is about. Just like to jump into it and and don't worry about doing the work. Yeah. Awesome.

Cool.

So, yeah. Uh, thank you so much everyone. Thank you so much again, Kev. It was, yeah, it was great AMA. Uh, one more office hours done and, uh, maybe one more left.

So, thank you so much everyone. Awesome. Cool. All right. Thanks for having me.

See you guys.

Bye.

Thank you so much.