All Core Devs - Consensus #188

Transcript

Alex Stokes: Hello! Just checking, can people hear me?

Matthew Keil: Loud and clear.

Alex Stokes: Okay, thanks. Been having some headphone issues lately, just wanted to make sure. Okay, so I think the way this is set up now is, this is streaming from Zoom, and it's already started. So, let's give people maybe another minute or two, and then we'll get started. Okay. We're just about at 50 there we go. So, yeah, it says we're 50 people. Feels like a good number to get started with. So

Hello, everyone. This is ACDC number 188. It's issue 2227 in the PM repo. I put the link here to the agenda. And, yeah, let's go ahead and get started. So today, we should touch on Glamsterdam, as I think everyone hopefully knows, Sepolia Is forking, next week? Then we'll move to Hegota. We'll continue the scoping conversation, working through the list of EIPs there. And then there are a few other comments along the way. So let's go ahead and get into that. For Glamsterdam, I just have to ask, any relevant updates from any devnets or, you know, similar testing we've been doing over, say, the last week? I imagine we're pretty good here, but I would just ask.

If there's anything anyone would like to share.

Barnabas Busa: We are preparing a Sepolia Shadow Fork as we speak right now. We are done with the Muzits right now and hopefully launching within the next hour or so. We're expecting the shadow fork to be alive for a day or two. Probably we'll be shutting it off before the weekend begins. We just want to send to check that everything is, working as expected before the fork.

Alex Stokes: Yep, makes sense. Alright, amazing. Cool. Then we'll turn to the Sepolia upgrade itself. Let's see here, let me just make sure I have the exact right date. Okay. So Sepolia will be forking to Glamsterdam on October 6th, at… You know, it's seven minutes before two PM UTC. So that's… 1pm, 53 minutes. And… Yeah, I don't know what else to say there, The fork is soon. That's… let's see… depending on your time zone, it's something like next Tuesday, so… It's coming down the pipeline. And, yeah, should be exciting. Again, I know everyone here has put in a ton of work to get to this point. So We will start the network upgrade season. We'll start with Sepolia.

Assuming that goes well, we'll move to Hoodi and then ultimately Mainnet. So Unless, yeah, there are any other general comments here. I did want to touch on… the incident response plan. Actually, let me grab a link really quickly… So, if you go to the PM repo… And I just had this. Okay, protocol upgrades. So, Barnabas, just to your question, did we already pick a Hoodi date? And the answer is no. As far as I know, we have not. Yeah. Unless something's changed, maybe it was discussed on ACDT this week. I'm not sure. But the last that we had discussed here was that we wanted Sepolia to go well. Then we would pick a date for Hoodi.

I think we had said something roughly, like… Let me look at the calendar again. Okay. I don't remember. It was either the twentieth or the twenty seventh. Okay. It was the twenty seventh, maybe the twenty sixth, one of these days. Essentially just the week before Devcon. So I imagine if Sepolia goes well. then, we should go ahead and have that discussion on ACD next week, during ACDE, so… Let's, do that then. Okay, jumping back to the topic here. So we have this document I linked. Protocol upgrade under processes, again on the PM repo. This document is kind of long, but there's a lot of good stuff in here. Many of you were involved with the drafting of it, and ultimately, this has come out of our experience of doing

Dustin upgrades, even mainnet, kind of this whole end-to-end process. And, ultimately, it just encodes, you know, I think some good postures to have in the event something goes wrong. And, you know, to be clear. We're all hoping and expecting things to go super well. But in the event they don't, it's good to have a plan to fall back on. Just so you know. If something does happen, you know, everyone will be on alert. This gives you just kind of, like, a nice framework to think about, okay. What do we need to do to get back to stable? Who's doing it? And how does that process kinda play out? So… From there… Let's see… I'm gonna give you a slightly more specific link here, to this incident response plan. And, again, usually how this works, this, especially, I think, for the testnets will be pretty lightweight. We just need to kind of have

Different people on point for different things. I wanted to ask today for client team coordinators, maybe before that point though. We'll jump into the others here. So I think to kick things off, I just wanted to introduce Will here as the communication coordinator. So, you know, he'll be helping to kind of, again, coordinate all these different things. I think Will's here on the call. Yeah. Will has been yeah. If you haven't met him yet, he's been, over many, many breakouts all over the place. So you probably run into him at some point. But yeah, so he'll be helping with just general comms in the event something does go wrong. Will, did you want to… did you have someone in mind for the DevOps Coordinator, Testing Coordinator, and Security Coordinator?

Just for Sepolia?

Will Corcoran: Not so much. We created the signal channel yesterday, and we've got, you know, the correct people from the EF teams, for security DevOps, and… Testing. And then, yeah, I guess the open question is the degree to which we… Wanting to have client team coordinators involved in the testnet versions of this.

Alex Stokes: Yeah. I think it would be good just to name explicit people. So, yeah, like, Pari here says that Barnabas and himself would be DevOps coordinators. No surprises there. And… yeah, you know, it's okay if teams, I think, need… you know, another day or two to nominate someone. But if you know today, please speak up. And if not, I can follow up async. But, again, just in the event something does go wrong, it's good that we have specific people on point.

Nixo: I posted the link to the, place where people can put their, their coordinators. It's already in the PM repo.

Alex Stokes: Oh, great, okay. Perfect, okay, excellent. Yeah. Okay. Yeah. This is helping me remember. Yeah. We yeah. Historically, people just made a PR to this. So then ask for client teams. Yeah. If you're not ready to label someone now. Just make a PR here. And okay. This is the mainnet document. I imagine it's not gonna make a huge difference, but if you want to have different people between the testnet and mainnet, that's perfectly okay. Just make it clear. And Barnabas says here, if you don't nominate someone, he'll be nominating for you, so… Go ahead and get ahead of that. I guess, yeah, ultimately, we have ACDT on Monday, so yeah, we can, touch on this again there, if… if necessary.

Okay. So I wanted to give that on everyone's plates, just something to have on your mind. Again, Sepolia should go well. We've put in a ton of R&D effort to get to this point, but good to have a plan just in case. Okay. I think that's it on Sepolia slash Glamsterdam. Any other comments or questions here? Okay. Great. Then, I guess we'll have one more ACD with ACDT on Monday, but then it will be time for the fork, so… Happy forking everyone. Let's move to Hegota now. And the main thing here is to continue with, scoping, and we have a number of EIPs. just to help you remember, the last ACDC, we DFI'd some, BFI'd some, and then had sort of this, like.

batch of EIPs where it wasn't, you know. And immediately, obvious yes or no. So, we should continue working through those. There have been a number of updates. one to one of the EIPs, where we had said last call, we wanted to update the IP before there'd be support. or CFI. There have been two EIPs that have been withdrawn, so… perhaps we'll just start with the withdrawn EIPs, just to get that out of the way. There's a comment here from lodekeeper, which looks like, an AI agent, which is pretty cool. Withdrawing 8333. This was Align Checkpoint with Epoch Boundary Block. I'm not sure if anyone on… Okay, sorry. I just saw the chat here. Let me do this. But yeah, is anyone from… Lodestar.

Slash associated with lodekeeper. Would you like to just…

cayman: Yeah, we look further to decouple consensus, and… It's just not worth dealing with it now, so… We just agreed to withdraw it and save everybody the… Hassle of debating this thing.

Alex Stokes: Okay, sounds good. Okay. I'm trying to share my screen. And, yeah, Ryan, you said, you'd like to make a comment. Can you can keep it brief? Yeah. I appreciate that.

Ryan Berckmans: Go ahead and do that now. I've been speaking extensively to folks involved in L2s and the app layer, and the general sentiment is that they would really like to see quick slots included. It's not so much that the reduction from 12 to 10 seconds is gonna be, you know, an operative benefit, immediately, it's that beginning the system of reducing slot time seems like something that would be great to get in front of now, to reduce the risk that slot times are still 12 seconds, you know, 3 to 4 years from now. We really like this one, we really appreciate all the work on it, and, you know, thanks for considering it. Okay. That's all. Thanks, guys. Appreciate everything. Have a good day.

Alex Stokes: Thank you. Yeah. So that's, yeah, statement in favor of quick slots. Let's not jump into that one just yet. Let's finish with these withdrawal EIPs just so the scope is, you know, the scope of the scope is smaller. Let's see. I'm trying to figure out sorry. I got okay. I wanted to get the chat up. Because it's a little hard when I'm also screen sharing. So… okay, I also lost the agenda. There's too many windows. Let's try it like this. Okay. So EIP-8333 is withdrawn. Yeah, for the reasons Cayman gave. Now… Okay, Zoom. So many, so many… questions. Comments. Okay, is that better? Okay, I can zoom in more, just so you guys see something here.

It's a little fragile here with all the different screens I have to juggle. Okay. So, 8333, and… okay, also then, we got a message, an update for 8363, this was the issuance change. There's a post here I linked on ETH Magicians, essentially saying that, it's been with John as well for consideration for Hegota. Yeah, the champions here. Realized, ultimately, you know, this wasn't the perfect venue for this, and wants to have a slightly different. Approach here with building towards consensus. Is Jerome on the call? I think he wanted to say something if he was. Okay. Anyway, yeah. So, essentially, yeah. The I dropped a link here. to the post from Jerome, it's, yeah, pretty straightforward, please take a look. But ultimately, yeah, just instead of pushing for, you know, kind of

shoehorning this into scoping, and it's not clear, you know, how ACD scoping squares with what should be, like, you know, a very broad community-driven process, given that this is more of, quote, a policy change. They decided to withdrawal and take a slightly different approach. There's even a schedule here in the post around. essentially a timeline for how they want to approach things. So, yeah, please take a look. Okay. So let me go back to the screen. Okay, I don't know if I can do this live, but ultimately… Just to call it out, so we have 8333 here, this has been withdrawn. We have 8363 here. This has been withdrawn. Okay. And let me just double check here. Okay, so then, going back to the agenda, we should probably just touch on 8365 next, so let's do that.

Okay. So, like I said, right, we had… Okay, title changed, I think. We had CFI 8015, And then we had discussed 8365. It had pretty broad client support. That being said, there was a part of the EIP that people wanted to see changed, and that's where we left it on the last call, was that we Yeah, the champions here are making updates and come back to present this again for CFI. So. That's where we're at. And the champion here is NC. Are you on the call? I'll hand it over to you. If so.

NC: Yeah, so the chain is pretty straightforward. Basically, just keep the deposit guard. part of the original EIP into EIP-8365. And then, the forced exit part is gonna be a standalone EIP. That would not be proposed for Hegota, but a future fork. Other than that, yeah, it's… It's pretty straightforward change.

Alex Stokes: Okay, great. Yeah, so… Yeah, proposal would be to go ahead and CFI this version of the IP. We had said last time that this is what we would do, so… everyone okay with that? Seems like there's plenty of support in the chat. Okay. Let's go ahead and CFI this then. Great. Thanks for the updates, NC. And, yeah, we'll go ahead and do that. I think there's a way… I can do this. And actually, we can track this. So yeah, we'll do CFI for that.

Marc Garreau: T. Alex. Yeah. There you go.

Alex Stokes: Yeah, can you see it?

Marc Garreau: Yeah, you're good.

Alex Stokes: Okay, thanks. yeah, Mark showed me this cool feature here. There's, like, a facilitator view to kind of do this live, which will be helpful, just because we have a number of these to go through. Yeah, just in case you're wondering, these markers don't go anywhere. It's more just yeah, a visual. It's just so we could track, and then yeah, this will be updated. on forecasts after the call with, these decisions, so… Cool. Okay, let me just make sure, I think now we can get into the rest of them. Just double checking… okay. Let's do that. Okay, from here, I figured we'd just kind of go top to bottom. The one thing is we had kind of said, given that 8411 was proposed pretty late in the process, we would kind of, again, hold it to the end of the scoping process, kinda do a first come first serve thing.

I think also at the same time, at least as of this, it looks like some clients haven't had time to weigh on this. So I propose we just hold this for later. And yeah, unless someone's super called to chat about it now. We can move to, like… yeah, well… This is a question. Let's just go ahead and do that. I mean, I think we kind of agreed last call that this was okay. In which case… We'll move to quick slots. Is Barnabe on the call? I know that he had wanted to…

Barnabe Monnot: Yep.

Alex Stokes: Save some words here. Okay.

Barnabe Monnot: Yeah, thank you. I have a couple slides. I think you need to stop sharing your screen so I can share mine. Just a few.

Alex Stokes: Okay, yeah, let's go for it.

Barnabe Monnot: Alright, can you see it?

Alex Stokes: Yep, I can.

Barnabe Monnot: Okay, cool. Yeah, I wanted to jump in today to make the case for considering for inclusion quick slots in Hegota. Wanted to give a bit of a status report, and what are the next steps here? Quick recap, we think, QuickSlots has a lot of value to ethereum users. You've heard it from Ryan a little bit before in the call. But just to like brush up on where exactly this value comes from, it's many different places. There's better UX from confirmation being faster. better markets from prices being updated more often, less MEV leaked to arbitragers, faster finality, faster confirmation rule as well. And more censorship resistance from having, more proposals per unit of time. So our thesis is that a faster ethereum in general

makes for more valuable Blockspace, which is value that accrues to the network, to the users, and to ETH as well, in particular. And if you don't want to take it from me, you can take it from 20 teams that are building very well-known applications on Ethereum who have given us quotes in support of, of quick slots in Hegota in this fairly long but very interesting ecosystem survey that we published. So as a recap again, our proposal for Hegota is basically two things. The first one is removing the hard-coded 12-second slot assumption where it exists, so both in client code, as well as tooling, as well as smart contracts that are deployed on-chain. And then, second step, proceed with a first decrease. So, our target for Hegota is 10 seconds. You may have seen 8 seconds in the EIP that's in the process of being

Updated, but our target really is, 10 seconds. Some of the progress since we proposed for inclusion. quick slots. The specs are now merged. You can check this PR5592. Shout out to Francesco, Jihoon, and Justine for their help with this. After the specs merge, I'm also reviewing the EIP, it's now in this branch, just waiting for Carl to do a review so that we can merge that. We have a Prysm prototype implementation that's ongoing, thanks to Terence. You can also find the PR here, and I'll link the slides in the chat after this. We're currently doing outreach after our ecosystem smart contract survey that we prepared with Sourcify, so what we did is we Analyze the Sourcify codebase.

We've just, like, static analysis, figure out, like, which contracts are relying on the… on the slot time, and we found quite a few, but we've… already have, like, some fairly, positive impressions from teams that have very valuable contracts that, tell us that, yeah, it's possible for them to… to make changes, so that, they adapt to the… to the new slot time. So, Lido off-chain, EFFI, like, these… these are all teams that have looked into the possible problems that come with, with a slot time change, and said they're okay with it, and in fact, in support. Of the quick slots proposal, generally. We also spent quite a bit of time thinking through the interactions with the transition to post-quantum, the transition to the decouple consensus, and to ZK proving. There's a bit more on that in our Hegota view, but what I would say is that we're very confident that 10 seconds in Hegota is not a blocker at all for any of these, transitions.

So, yeah, this is it for your consideration. Just to conclude here, EIP-8198 is really meant to open the door. Like, without it, we just literally cannot do latency improvements on the slot time, and take this first step that's moderate, but still, I think, very meaningful. And without committing that to Hegota, I don't think we can do that in ISTAR, given the size of decoupled consensus, so we're really committing to not having this door open for a long time. It's definitely significant, don't want to minimize that, but I think it's reasonable, according to a few people that I've been in contact with around… and code and testing, and I think it's a really high-value feature, so…

Definitely worth at least spending the time to look at it closely and understand the possible challenges. And I don't think there's a better time to start than now, especially if we're concerned with ecosystem implications. So, yeah, a CFI today would help us, like, continue de-risking the challenges, like, keep the momentum high. And as EF Labs, I think we're very dedicated, we'll support your efforts, we'll be active and responsive, and make sure that this goes as smoothly as possible. That's it for me.

Alex Stokes: Okay, thanks. Let's just take the hands here, Matt, and then Frederick.

Matthew Keil: I tend to stand on the other side of this discussion, and I side with Justin Traglia's sentiment, quite strongly, that, while it's not technically difficult in order to implement the short slots, I think it… the tuning of the client, like, it's not, it's not easy to tune the client in order to reduce slot times. And then, but more importantly, taking the focus off PQ, I think, is something that we really, really, really need to, be fervent about. PQ is an existential threat, and all development efforts really should be focused on that, in particular, decoupled consensus. There's one other piece of that that I think should be at least highlighted, is, decoupled consensus is gonna drastically rework how slot mechanics, are… are organized, and how work is scheduled within the slot. And I think there is, something to be said about, the potential of

shortening slots when we're doing decoupled consensus. because of how the rework happens, I think it opens the door for possibly even more drastic slot time reduction. But it feels kind of like chasing our tail to do so much effort in order to test shorter slots and prove it out now when we're literally going to be doing that Again… once we rework the slot mechanics. So… this is something that… that's my personal feeling. Our official stance as a team, though, is that we're open to the idea of adding the machinery in order to adjust slot times to the client, because again, it's not a technically difficult process in order to, to make that, something that is, you know, set with a flag or variable. However, the actual reduction of slot times is something that, I think is probably not best fit for Hegota. So that way we can spend the next, period of time working through

the challenges of what's required in order to tune the client and make sure that as slot times are reduced, we're scheduling work on the CPUs effectively. And testing that, with real-world numbers on Mainnet, not just on devnets.

Barnabe Monnot: Thanks. Should I reply now, Stokes?

Alex Stokes: Oh, sure, yeah, yeah, go for it.

Barnabe Monnot: Yeah, yeah, I think these are good thoughts. I would say there's 3 points in there. So, the first one is. about… Does 10 seconds threaten the post-quantum transition from, like, an architecture perspective? As in, like, is 10 seconds not enough time, for instance, to have the signatures? Are we painting ourselves in the corner with this? here, I think the answer is unequivocally no, like, because of the design of decoupled consensus, we're very, very confident that 10 seconds is just ample time to do the work necessary to do the fork choice on the slot time, so that's, in my opinion, not a problem. The second point is probably about, like, how much testing, is required. That testing will always be required whenever we want to change the slot time, but particularly so the first time we do so. And I think here the concern is more, should we be doing, like, all this work when PQ is an existential threat?

And any delay on Fox kind of threatens, like, doing that transition to PQ. I see the concern, I think. I would not… Go as strongly as if I didn't feel that, yeah, we're very, very like, vanishingly low probability we are threatening the PQ timeline at all. Like, if anything, I think I'm very bullish on us moving to PQ infrastructure as soon as possible. So in… in that respect, yeah, I think this is why, to me, CFI need today would help a lot, like, have more eyes on how much work is this exactly in terms of testing on the clients and everything, so I would really welcome Us, like, taking a very strong look here. And then on the third point.

Should we just bundle that with decoupled consensus? I'm not particularly confident speaking to people who are working on decoupled consensus that they would think it's reasonable to do both at the same time, like. decoupled consensus changes a lot of things. One thing it doesn't change that much, actually, is the slot structure. Like, this is still a blog that is produced, and then there's a row of attesters. In fact, it's a subcommittee of them, so 512, so much smaller than today. you will have the ePBS mechanics, you'll have FOCIL, so there's not that many things that change in terms of the slot mechanics, where Yeah, so it means, like, if we do do the work of making the slot time reduction in Hagota.

not like very little to none of that work is is wasted because decoupled Consensus kind of throws all of that out of the window. This is not at all the case, as far as I… as I know. But yeah, these are just counter-arguments. I understand that some of them, obviously, are subjective, but I think for me, still would lean to CFI so that we can do the proper due diligence in terms of testing and changes.

Alex Stokes: Okay, let's go by hands here. I think we're at Frederick, then Ben, then Barnabas.

Fredrik Svantes: Yeah, I don't question the usefulness or the value of Quick Slots and I think It's definitely something we should strive for and implement, and we should strive for something that's much less than 10 seconds, what the lower bound is, I'm not sure, but I hope we can get very, very, very low. And I know that Barnabe and everyone else who's working on this are… like, great researchers, and they are… they do have the ability to look at all the edge cases and so forth. My concern is… I guess, similar to Matt, how this will… affect our ability to basically secure Ethereum from the post-quantum threat, and I think… we've been talking about 2030, etc, but I do think this is likely to accelerate. Who knows what's going to happen from an AI point of view next year?

And it might not be that a post-quantum computer arrives, it might just be that existing cryptography is broken in various ways, and the sooner we can migrate away to something that's more secure, that's probably better. And I guess my… Where is that… quick slots in some way might end up delaying Heguta, primarily because of these unknowns that might affect the ecosystem at large. So basically, I'm primarily concerned about that. I'm not sure how long it will take from a technical point of view to implement. Quick slots… But unless it's very easy, then… I mean, that basically means that CL teams are spending time on implementing quick slots instead of starting on the PQ items in ISTAR, for example.

Maybe some kind of a middle way here could be to say, you know. EF is very easy to implement this, technically. And… It turns out that… Actually lowering it from 12 seconds to 10 seconds is going to… take months of research and reaching out to ecosystem and so forth, then maybe there could be an agreement to just simply keep it at 12 seconds, and do the, like, lower the amount later. But again, I'm not sure how long this would take from a technical implementation point of view. If we're talking months, or… days or weeks for most of the clients, so I think that would be interesting to hear as well.

Alex Stokes: Oh, no, yeah, go ahead, Bernaman, if you had a response.

Barnabe Monnot: Just a couple of thoughts. Yeah, I think, I mean, still agree on this might be work, and we have to be mindful of any work that delays, shipping Hegota. on its own, because I think delaying forks is never nice, but also in the context of the PQ transition. I hear in what Frederick said, and also what Matt said, like, this idea of maybe there's exit ramps, where we can do some of the work, but then we can decide later whether to move from 12 to 10. I… I mean, we can always do that, like, in principle. There's work that can be done on the clients to remove some of the dependencies, but then keep 12 seconds in there. I think it's still worth pushing for 10 seconds. Like, in my opinion, it's not really the…

like, moving from 12 to 10, that's, like, the hard part. I think it's more about preparing all the test beds to test these things, making sure that, the client tunings that Matt was talking about, you also have, like, ways to Yeah, to inject the right values, essentially, so… So yes, I think… The work, anyways, will look like, allowing us to change the slot time, and then making that slot time change. My guess, from where I stand today, is doing the work of allowing ourselves the slot time will very likely lead us to to understand that, yeah, going then from 12 to 10 is not that much work, but… Then again, I think we need more data on this.

Fredrik Svantes: But I think, like… On the protocol level, changing from 12 to 10 probably isn't the hardest part, isn't it? More… let's say, the ecosystem point of view. I think you guys had Sourcify do some kind of analysis on contracts that would be affected by this, and so forth.

Barnabe Monnot: Yeah, but we're we're going to do this work anyways of reaching out to every smart contract that we identified, and we already like started with with this work. Like, we can't delay that until we have certainty that, oh, actually, yes, we are flipping the switch from 12 to 10. Like, some of these smart contracts, they need, I don't know, there's governance, there's delays and stuff like this, so… so there's no reason to… backload that work until we make the active decision, let's say, to go from 12 to 10. So we started already, as of a month ago, we're doing that, like, fairly rigorously at the moment. I think it would help, actually, to At the CFI, some of the teams, sometimes we have to spend some time thinking about their

their contracts and everything, so they want to make sure that it's not time that they are wasting. But yeah, this work is definitely happening and we're very serious about doing it properly over the next weeks and months.

Fredrik Svantes: And how many contracts was… like, would be affected by this?

Barnabe Monnot: I think there is… 100 contracts that I would say… Our main contracts, obviously, like, the… The static analysis detected a lot more, because there's many contracts that are just, like, forks of well-known contracts. But I would say, yeah, order of magnitude, there's probably 100 that we need to be Thinking clearly about, how does it… get mitigated here? Who is the team to reach out to? Yeah. I don't think it's infeasible, and again, like, many contracts are just, like, forks of other contracts, so once we figure it out for one, it's not that hard to figure out for others.

Alex Stokes: Okay. Ben, then Barnabas, then Matt.

Ben Adams: Yeah, I mean, so the EL has, in Glamsterdam, has the slot num opcode, which, so you, you don't need to use the timestamp versus the Okay. Blocks. To work out what SLOT is. But also, it seems like… doing… I mean, you can do the work, otherwise the work will never get done, it'll just get postponed and postponed. But then maybe if people are a little bit hesitant, you can hold it at 12 on the actual fork. And it's been mentioned in… chat, do something like a BPO. Mid-fork? To… to bring down the… the slot time. As an option.

Alex Stokes: Yeah, I think… The simpler the better. But, yeah, I'll just pause there. Barnabas and then Matt.

Barnabas Busa: Yeah, so my point is basically, what I also put in the chat, that Personally, I feel like we shouldn't make up the protocol today, just out of the fear of what, post-quantum will require later. Like, we are not at the point right now where we could be implementing post-quantum work just yet. So, just out of the fear of that, we shouldn't be limiting what we start including in the protocol today. I think we should do our best effort in improving the protocol, and in case later on, this seems like a bad decision, then we can always revert back to 12, or if… if needed, even more, because this EIP will actually allow us to adjust this later on at.

But the future Epoch as well. I know that that's not something that we want to do, but it's something we could do. And yeah, if every client implements this array feature. I I think it's it's a EIP that should be included. Or, Heather?

Alex Stokes: To be clear, when you say array feature, is it something like, you know, this slot param only type thing, or, like, how we handle VPOs?

Barnabas Busa: That's… that's basically how it was added in the, config yaml right now. There's an array for it, where we define, at specific EPOC, we will use this slot time. And we are planning to deprecate the, old, seconds per slot, which is already gone, and the… Slot period, millisecond, or… I'm not sure what the…

Alex Stokes: whatever.

Barnabas Busa: But that can also be deprecated, once this array is being used.

Alex Stokes: Yeah. And just to make it clear, like. There's how this is sort of configured or parameterized in the client with, you know, this is, like, the config that Barnabas is talking about right now. I do think we should keep clear that this SPO idea is separate, and, like, the difference is that You know, changing it at a hard fork, which has a lot of attention on it, is… yeah, I think different to how we do BPOs. Not that BPOs don't have as much attention, but… Yeah, it does feel a bit different. Anyway, Matt.

Matthew Keil: Thank you. I do tend to, disagree with Barnabas that. we could increase slot times. I think that's never going to ever happen. Like once a market gets something, it's impossible to go back. And I think this is also part of the sentiment that initially I pushed back on even adding the complexity of being able to modify slot times because there's going to be pressure in order to reduce the slot time. At every single fork and I, while I agree that it's a very important thing. for the protocol. So I don't necessarily think we're going to kneecap the protocol by not shortening slot times. But at the same time, there's going to be intense pressure because of the economic benefit that comes from shorter slot times and arbitrage opportunities, and really, which is the best benefit, like, the most important thing that you're going to get out of shorter slot times is cross-chain arbitrage. And…

There is just so many other things that the teams need to be focused on right now, in particular PQ, privacy, encrypted mempools. Like there's just a ton of features that I think are more important than increasing profitability of certain stakers or excuse me, certain stakeholders. I do agree that it's very important in order to shorten slot times. Sure. And this is why I think we have, we as a team have advocated to add the machinery in order to be able to make that adjustable. But there is one other piece of this, is that 10 seconds was kind of arbitrarily chosen, because it felt like a… and I don't know this to be a fact, I just…

after reading the chat, it feels like a politically feasible target. Like, 10 seconds is not that much of a difference, but, like, there's no real backing that says that that's the right number, or it's like a toe in the door, and this is where the idea of adding the machinery to the clients now, at H, but not actually adjusting the slot times, and then it's relatively easy to dial that as we go forward. But we would have the machinery in order to be able to get real-world metrics, we'd be able to test to see how things are actually working, and we're pulling the testing, which is going to be very… it's… like, the amount of effort to add the machinery to dial the slot times is very easy. Literally, we built it in 10 minutes. The thing that's difficult is scheduling work on the CPUs when you've got an EL that's running

faster and you've got a seal that's running faster. And like, this is where the rubber hits the road. It's, it is, there's going to be hot pass that come up and it's not like, it's not like your timers in, in the client are just going to scale linearly and you're not going to have any issues. There's going to be hot pass that come up that are going to be different today than they are, at 12 seconds or excuse me, that are going to be different at 10 seconds than they are at 12 seconds. And when you get to decouple consensus, that thing is going to apply is that the work is going to be spread throughout the slot in a very different way, especially with aggregations coming out of slot-wise mechanics. So, like, because of that, there's going to be a very different scheduling of work when it comes to what happens on core, and we have no idea what that looks like. And we also don't know what it looks like when you go to 10 seconds, and there's just a ton of variables, and it feels like an optimization that is

is… I don't know if premature is the right word to say, but it feels like it's… it's… it just needs to wait for the decouple consensus, which is critical for the PQ roadmap, because of how long aggregations take, so that we can properly test, what the adequate slot time is.

Barnabe Monnot: And maybe a quick reply here, I… Yeah, I agree that 10 seconds looks like a bit of a magic number, but I will say that to me, the most pressure on not going lower than 10 seconds came from concerns around the proving time and zkVM, and are we able to get real-time proving fast enough with 10 seconds? So it's a lot of, like. decision-making under uncertainty, because, yeah, when are we shipping X, Y, or Z, and what will be the performance by then, etc. Like, for PQ, again, like, given the design of decoupled consensus, using a subcommittee, not aggregating, having 512 validators with a 1KB signatures.

Miguel: Nick.

Barnabe Monnot: It just feels like every measurement today tells us that this is easily feasible, and not really the bottleneck of a constraint that we would hit first. But yeah, obviously, like, more testing, always better. So, not claiming that this shouldn't be done, but would love to… to make that possible.

Alex Stokes: Okay, thanks, everyone. There are obviously many considerations here. I do want to be mindful of time, but it would be nice to hear from some other client teams, who… ranked in favor of CFI in this. I feel like we've heard… So far from, you know, people with reasonable concerns, but… Following along in the chat here. Yeah. It's it was a little tricky, but, you know, just to surface some things, I think a number of people chimed in saying that, yeah, you know, technically, to get the parameterization in place. You know, that's actually not a big deal, pretty straightforward. Yeah, and I think some of the other people who… Rated this well in their client rankings, or also speaking of Aver.

So okay, we have some hands. Now, let's do Terence Walter, then Salius.

Terence Tsao: Hi, yeah, so I think Prysm Team rated, A. I think it was mostly between S and A, but we only want to give one S, and then we found that faster execution, or faster block. is more important and slightly easier, because it essentially gives more, room for broadcast, so it kind of sets up quick slots nicely. In terms of implementation, Prysm has a prototype, and then. When he was on leave, I also picked up the prototype, and then I updated it against the latest spec. We have gone through some several weeks of fairly, I would say, detailed-ish audit on what the changes on the Prysm codebase, with the help of AI. And then, I would say overall, like, I mean, it's not easy. I mean, so is every other EIP is not easy, right? Unless your EIP is something like.

8015, something I propose, and then every EIP is hard, right? Every EIP is engineering challenge. The question is whether the trade-off is worth it, and I… we think the trade-off is worth it. We think, like. it's important to reduce the stall time, and then we shouldn't wait for another… if we don't do it now, we have to wait another 3 years to reduce the stall time, and to us, it just seems like a no-brainer to do it now. But yeah, that's… that's our take.

Alex Stokes: Okay, thanks. Walter, Solius, and then Lukasz, and then I think we should probably move on after that.

Walter Himmelsbach: CPU is now really expensive. Did, we can buy CPUs in the next, years a little bit cheaper, what do you think?

Alex Stokes: Do I think CPUs will be cheaper in the future? That's a good question. Yeah. Let's just assume they will be. Solius?

Miguel: Yes, CPUs are expensive.

Saulius Grigaitis: Yes, we are not in support of the EIP and I think that Maybe a way to move forward with that would be something similar like we had with the stable containers, where essentially the feature was not accepted at the beginning. And then some teams pushed it, and during the hard fork implementation, it was… it became clear that it's possible to ship it. So my suggestion would be, as there is some people that are pushing shorter slots, I think maybe we can just not accepted for now, but some teams could push it and share their experience, and then maybe it will happen, you know, in a few months or so, after it becomes much more clear what are the efforts to ship this quick slots.

Barnabas Busa: It's usually the other way around. We CFI first and then find out if it's problematic, then we drop it because the scoping would end by the end of this month.

Saulius Grigaitis: Well, I'm, I mean, I don't like to, to, you know, to, to agree to this feature right now. I mean, I think it's… it will… it's really something that will delay the, the hard work.

Alex Stokes: Yeah, I mean, I think the ask is more agreed to accept doing the work now, so that we can then, you know, be in a better place to make the right call. Lukasz, Terrence, and then Enrico, okay, and then after Enrico, we should definitely move on.

Łukasz Rozmej: Two points from me. We'll try to be quick. CPUs, I don't know what you guys are planning to do. CPUs currently tail block processing on EL is from 50 to 200 milliseconds, depending on the On the client and on the reference hardware, so I don't think CPU is a problem. BALs will increase that a little bit, but, or maybe not, we'll see, but I don't expect huge changes. So we not a problem, in my opinion, from the EL side, even in the Crist load. I don't know what is planned on CL. So we'll see about that. But I don't see CPU as a problem. And zkvms and I'm telling from the person who's currently optimizing guest program for zkvm

I wouldn't allow them to hold the protocol hostage and improvements to the protocol hostage. They need to keep up both zkvm and guest programs. They need to be optimized. And here we can at least throw more hardware at the problem if really needed, so, I don't see this as a blocker either, so never mind this for, shorter slots. I wouldn't commit to any, actual numbers, before we measure them, but I would, I would, I am very far, actually… Putting the work to be able to do it.

Alex Stokes: Okay, Enrico and Terrence, you can have 10 seconds. Okay.

Terence Tsao: Yeah, I would say to Saulius point, right, if we were, oh, sorry, go ahead, Enrico, did you want to say something?

Enrico Del Fante: Was mute. Sorry. Yeah, just a quick update. So Teku put it in S. We have this On the implementation side, we believe it's not that complicated. I do think, personally, that it's worth having, and I don't actually buy much the argument from Matthew on the CPU things, because we change every time the slot, and how the hot path… hot path on the… on the SLOTR. are happening even now in Luas. There will be a lot of changes, and… in Hegota with FOCIL, there are… there will be others, probably. So… That seems like a weak argument to me, but I feel instead the argument of Opening the door of future pressure to shortening the slot, because now it's easy and just a parameter change, and there will be some economical pressure to

to… to shorten, even if I believe that A technical argument to not do that will stand because it's not just the technical implementation. There will be other reason why we can push back. So I definitely believe that this… this machinery should… should go in, and then we can… Make the old ecosystem smart contract analysis, thing to actually kick, kick. Kick the work there, and make this thing move forward.

Alex Stokes: Okay, Terrence, did you have… a very.

Terence Tsao: No, that's okay.

Alex Stokes: Okay.

Terence Tsao: Yes, you can go.

Alex Stokes: Okay, thanks. So okay. Yeah. Again, thanks, everyone. And you see there's a lot going on here. But, yeah, ultimately, you know, in terms of distilling rough consensus. I do feel like it is what Barnabe has here in the chat. Everyone agrees to the value, both here, but also, you know, broadly in the community, and… Given the sort of stage approach that, you know, we've been discussing throughout this call. of going ahead with CFI today, you know, put in this additional legwork, to validate, you know, specific numbers and things. we go ahead and do that, and that gives us another point later in time that, you know, if we need to pull it out, we can. So, you know, that actually maps quite well to CFI today. And then before we SFI.

you know, we'll have time to dig deeper into all these things everyone is bringing up. So… I feel like that's a pretty nice way to move forward. Shall we do that? Okay. Getting some thumbs up. Okay. So let's go in CFI and again the understanding here is that you know we still want some more data to validate the change from twelve to ten. there will be, you know, the opportunity to revisit this before it goes to SFI in the event that things come up in implementation. So…

Ben Adams: Do you rush? Could you share screen again?

Alex Stokes: Yep. Okay. Can everyone see this? Okay, I'll just assume that you can. I… here, let me get the chat back up. anyway. Okay, so CFI quick slots, again, some caveats here around getting DASFI, but I think we all understand What needs to be done there? Okay. Let's see. So we have about thirty minutes left. Let's keep trying to get through these. Okay. Next one up, then, would be 8379. This is Top Up Sync. Let's see. Dustin here is listed as as the champion. Would you like to say anything about this? And then from there, we can get into client opinions.

Dustin Brody: Yeah, so I can… so first I can, I just have a, A slide, but I, you know, it's not, it's not super critical, I don't have a whole presentation in the sense that, you know, Barnabe did. So I want to… Essentially, this is a way of, of Driving… so the CL can… can drive the sync on the EL side, and… and it can do so by, sort of distinguishing between different kinds of, sort of… so if we have a blockhead and execution head, as if… so where… how many blocks this… the EL might have, even if it hasn't calculated the state through that, which means it can backfill the block from the exact right place the EL, rather, needs to actually sync.

which is a capability that doesn't really exist today. So, and I would say there's a few general items that sort of enable sort of functionalities, resilience that we don't have in a standardized way right now. One is, as we're talking about sort of potential sort of recovery plans, and earlier on. Well, one of the things here is that one of… In Pectra, in Holesky, one of the things that went wrong, right, is that when you had the CLs and ELs, the CLs couldn't actually sync fully properly without the ELs, syncing. And both found it difficult for the same forked chain reasons, but both at the same time was even more unlikely, and that made it more likely to get stuck, so therefore, this would enable… only the CL has to stay synced, the EL can

sort of follow along with this CL much more directly. So that sort of enables resilience there. So that's the point one. Point two is it enables, it reduces duplicate and inefficient gossip traffic, in a much more, systematic way. The ELs can simply stop listening if they… if they choose, right? This is a… it adds flexibility. This is all optional, right? But… but they can… they can… Avoid, listening to certain, on certain things they have to listen to today, without actually losing functionality, and this reduces all sorts of surface, attack surface as well on the ELs, potentially, as well as, in a longer term, potentially we can look at a sort of less-protocol reliance on our ethereum overall. And finally, the third or fourth, depending on how you're counting, I'll wrap up here, and then we can, you know.

So try to be quickish about this, is it enables a broad concept of a flexible delineation between exactly how and where storage is deduplicated. Between CLs and ELs. Now, right now, this is, something that some CLs and ELs already do, obviously. Some CLs will offload payloads in the future. I'm sure envelopes say to ELs, things like this. So, this… this allows for an arbitrary kind of set point to be defined at some level, because you can kind of load up the EL with it, and then the… or the EL can… can drop things, and they can be re-added, and it can… it can be this, somewhat bidirectional thing that, yeah, can be tuned in a flexible way. So, I'll… there's some other points, but I'll stop there, and then, you know, have some…

Discussion.

Alex Stokes: Marion, thanks. Let's see, I think I can see hands here, and the UI… So, yeah, any comments immediately, Lukash?

Łukasz Rozmej: So, our concerns with TopUpSync are that we extremely optimize our sync process on the EL side, and this, is. This EIP… is… Removing… Our control from us, to some extent, so we are very wary of it, and… That's our problem with it.

Alex Stokes: How do you lose control?

Dustin Brody: So.

Alex Stokes: I didn't follow. Or yeah, Dustin, you can jump in. Well…

Dustin Brody: No, no, I'll, I'll, I'll, I'll, no, if Lukasz wants to, you know, I'll say, I'll. See, wait for responses.

Łukasz Rozmej: Or did I, or did I, or did I, confuse the APs? Okay, let me get, get back, actually, sorry. Maybe… I confused the EIPs because there are two sync EIPs in proposed. Sorry, I'm not sure. I got confused. Too many things.

Dustin Brody: Oh, oh, oh. Oh, okay, okay.

Alex Stokes: Can you tell us Dustin does it? I'm also I haven't had time to look at this too deeply. And it sounds like it's just exposing more information from the EL, which the CL can.

Dustin Brody: Right.

Alex Stokes: However it wants.

Dustin Brody: Yes. No, so I would say it removes zero control from ELs. The one thing it qualitatively newly asks from ELs, really, is it has to… so… This, this end… this, It's called engine I mean, currently called engine get sync status, but that obviously can be Bike shedded endlessly. And in fact, I should say in in honesty, it's it's really aimed more at an SSZ world, so it would be renamed anyway. But, yeah, you know, just synchronization of of EIPs in that kind of sense here. So, but this endpoint, but this is an informational endpoint. This is a reading endpoint more than anything else. This is not, this doesn't ask the EL to do anything. It gets information from the EL.

And so in that sense and and then what CLs do with this, is then up to the CLs, but the ELs can then React as they will, but yeah, it does not remove any control, no.

Alex Stokes: Francesco, you had a hand. But it disappeared.

Francesco D'Amato: No, it was from Guadalupe.

Alex Stokes: Different Francesco, Risitano Tau.

Francesco Risitano: Yeah, I was just, gonna touch on the point of, efficiency. I guess I was also confused because, I was of the understanding that, the CL would be feeding blocks to the EL for sync. Which may have also been Lukasz's, point around efficiency, because the ELs have, you know, highly parallelized, pipelines for syncing. You can just, provide the sync target over the engine API, and then, yeah, the ELs can use. Those processes to sync, to the chain tip, essentially. And I believe there's, like, an alternative which was DFI'd, which was 8237, which was more aligned with, kind of, delegating EL sync to the EL, and then just having, like, a binding commitment, once the sync is completed, to kind of ensure, cross-chain consistency.

But yeah.

Dustin Brody: Okay, so… The. And. Sorry, so actually, first I want to say, as far as Lukasz's, the The so I. Sorry, the, Lukasz's thing about the, I don't see the loss of control in that so, like, I'll just say. But anyways, as far as the efficient pipeline, The, yeah, this is not meant to replace like the snap sync say, like from, from. From. To a recent pivot. Like, it's not going to be efficient at that, because it is serial. And especially if you're talking about, anything where it has no way to direct the EL to, like, get the state, like what SnapSync can do, and then efficiently build on that, especially as we're going into a sort of, I guess, are we still calling it 4-4s? But the sort of, expiry.

history expiry world where the whole history won't even be available. Right? So indeed, that it's it's complementary to that. Right? It it is not the point is not to replace, you know, you're going from Genesis block by block by block by block. That would be generally absurd.

Łukasz Rozmej: Yes, but even if we have a relatively small gap, we, currently, and I don't know, have to think, let's say… thousand blocks. We do it very aggressively, in parallel onto multiple peers, and… you know, we spread the load, etc, and get that in. resolved in a matter of seconds, literally, if you have the bandwidth and CPU, and now we will have to wait for someone to feed those, and… It's out of our control.

Dustin Brody: Well, it doesn't require the EL this is it does not require the EL not to do this. Right? The nothing about this EIP requires the only the only specific change that this EIP requires is this new endpoint. That's it.

Łukasz Rozmej: Okay, then it needs to be spaced. yeah, specified, because this read for me like it was okay. Now you don't do anything, and you wait for us to feed you the data.

Dustin Brody: No, I, I see, I see, no, it, it is that, ok, so that is sketching out possible worlds, possible ways of one could create an EL, and whether this is a good idea or not is a different question, and I… to your point about the efficiency and getting things in with, you know, enough peers in parallel and doing things in seconds, I understand that. But. that is a… it basically, it creates the possibility of, for example, kind of the library EL, which can't really exist today, but that there's not… every existing EL or any EL which wants to use the existing, their own sort of sync mechanisms can absolutely continue to do so. And if that's not clear in the EIP, I can certainly make that clearer. But yes, that's what… part of what I mean by optional with that, what we mean by optional, I guess, three authors.

Alex Stokes: Okay. Let me jump in here. Yeah, Enrico, I wanted to hear from other SEAL teams just while we're here.

Enrico Del Fante: Just one quick comment. So, this belief… this enables possible ways of thinking, and then there was another EIP that was taking a completely different direction, assuming that CL doesn't want to take care of anything about payloads, and want to fully, fully give up and let the EL do completely its own thinking. So there are two completely different approaches, and I get the fact that this DCIP could enable different approaches, but I believe that the end game is not having multiple possible scenarios. I believe that those two things need to be discussed. So, what… I believe in one of the, meetings that we had, somewhere. we discussed the fact… we need to think about what will be the end… the end deployment of CL and EL, which are… which will be the responsibility, and then when we… when we envision what we… what we want as an end game, then we…

We decide to go in one direction or the other. Keep having both possible conditions, I believe, is just not addressing the issue. But we should actually be clear on. On the responsibility, on one side and on the other, and going in one direction.

Alex Stokes: Any response to that, Dustin?

Dustin Brody: about, what, defining specific areas of responsibility and sort of making that… codifying that? I don't necessarily… I mean, at one level, you can see this EIP as moving that towards the CL side, if you'd like, but at the same time. it is optional, and so I don't want to emphasize that too much in the sense of saying the ELs can still do everything per Lukasz's question before, etc, that That they do today, but yeah, I mean, at some level, it envisions a world where it's kind of CL driven in that, in that sense, if you want to frame it that way. But again, that is optional in that sense. And ELs can just ignore this.

Enrico Del Fante: Yeah, it seems like we are spending time and effort doing something that, without Without taking the decisions on. what will be the end game. So in some sense we should do some planning first. And then… And then go in one direction.

Alex Stokes: Would it help to take this to ACD next week? Or, I guess, whenever they can get to it.

Dustin Brody: I mean, I'm wondering, though, in terms of, like, the other thing was, it was DFI'd, so, I mean, One Direction was considered, and that was not taken. So. I mean…

Enrico Del Fante: Which means DFI also this one, and take the argument one.

Dustin Brody: I… okay, I don't necessarily obviously agree with that.

Enrico Del Fante: Nice.

Dustin Brody: or understand it. Well, no, but to say, like, I just say, oh, one thing on one topic is DFI, therefore all things on that topic must be DFI, I think is not sound reasoning, but. Sure. In any case, I mean, I kind of addressed your question, though, about like, well, it does pick a side to some extent. It says that. That it offers some. Visibility in the process from ELs but I also don't necessarily buy your framing, honestly like the idea that we Have to, like, pick a, like… yeah, I… The way you're setting this up is not something I necessarily think is. as.

Enrico Del Fante: I mean, is…

Dustin Brody: wired?

Enrico Del Fante: Network efficiency. So you need to.

Dustin Brody: Yes.

Enrico Del Fante: One Direction, because you don't want to have always the duplication of things going on one.

Dustin Brody: Yes.

Enrico Del Fante: And on the other. So, at some point, you need to take the decision, so you cannot maintain one approach, because the net… 90% of the network goes into another direction. So, it won't work. If we want to make an efficient and real deduplication, we need to take decisions.

Dustin Brody: Well, the… Right now, the status quo is there's a certain amount of duplication, on the gossip side, and I'm putting aside sync, because as we've sort of discussed, like, sync is… And storage. Yes. Yeah. Gossip and storage. But sync is is look. It's a separate issue. Snap sync, etcetera, we've got it is not gonna replace that.

Walter Himmelsbach: and.

Dustin Brody: realistic world for the most part, fine. But for gossip and storage, yes. And and so in that regard, Right, the status quo today is we have that inefficiency, and this would allow tools on a node-by-node basis to opt in to reducing that inefficiency. And yes, the way they opt in to reducing that inefficiency, it would be by moving it practically from toss it from the EL if they choose to do this. If the CL and EL are configured for that node pair to do this. And so that enables a fairly safe, gradual transition towards that side, if that's what one wants to do. So that is, to the extent you're asking for, like, a side to be picked, it picks that… the CL side.

Alex Stokes: Are there any other CL teams or, I mean, even EL teams here that wanna speak in support of the CIP? Because I'm not hearing a lot of support. There was a comment from… Part of us about essentially just, you know, we could have this we can move ahead with this as an optional thing where it's not necessarily scheduled for the hard fork, but, you know, if You know, a given pair of clients wants to implement this, then they can move forward. Francesco then came in.

Francesco Risitano: Yeah, I'm just following on from the vision of having the EL kind of inside the CL as a, library. Would this method, still be required? Because one would assume that, the CL has direct access to state, of the EL library, so to speak, and can, you know, simply query the database or whatever storage mechanism, the CL is using. So, does this still make sense in the, kind of, unified client world?

Dustin Brody: Full-on unified client, not quite as much, but it does allow for a standardized interface, which still has… which still has significant value in a case where they are not literally the same thing. So they can communicate through, say, a local RPC, any number of options like that. And whether or not that ends up being the shape of quote-unquote unified clients people end up wanting is actually not that clear to me. It's not been a well-explored space, let's say, but for certain parts of that design space, it still provides value.

Alex Stokes: Karen?

cayman: Yeah, just voicing some support for this EIP from, I think, from my perspective, it looks like a minor engine Api tweak that doesn't really mandate any Changing behavior of clients and unlock some flexibility. that… we want to. Some people want to explore. So I I say, let them cook if it's a small thing, but it's optional. So That's it.

Alex Stokes: Mark, you have your hand up?

Mark Mackey: Yeah, I mean, I need to verify this, but if it is, especially if it is just engine API tweaks, we have, I want to point out that we have the Git capabilities. Like… Endpoint, and so… We could potentially utilize that to even decouple this upgrade from a hard fork.

Dustin Brody: So… so the challenge with GET or exchange capabilities, or I believe it's what it's called, but GET capabilities, exchange capabilities, the, is that it's, it's a talk-to. It is simply not reliable over multiplexers. We know people use these. Sometimes they use them without telling us. But the endpoints are not stable. The endpoint identities on the other end are not stable. So like an EL can get upgraded or downgraded. It can swap to another EL, which may or may not support the same set of things. You end up having to get into. Caching, you know, do you cache the answer? Does it get… do you try it optimistically? Etc. So, I mean, without getting into too much of the weeds there, the point is, like, the…

This capabilities discovery is not a great general purpose mechanism, and not something that's ideal to rely on.

Alex Stokes: Okay. Thanks, everyone. I do think, yeah, we should go ahead and wrap up on this topic. again, I'm not hearing a ton of support, I think, from the people who are supporting this. They're very open to it being an optional thing that's outside of the hardcore cadence. So then, you know, with the frame of keeping the works, you know, as light as we can. this feels like a DFI today, but of course, if you want to move ahead with adding these engine API endpoints, you know, you definitely should. So, let's go ahead and DFI this with that understanding. Does that work for everyone? Okay. I'm not getting… any response, so I'll just go ahead and assume.

That sounds good. So… Let's go ahead and say DFI this. Although, again, you know, if you wanna experiment with, you know, what this EIP would enable, you definitely can. Yeah. Okay. Then let's go to the next EIP. We just have a few minutes, so let's see what we can do here. The next one here is EIP-8383. Reduce CL block retention window. Let's see, I think this was… yeah, Kev, is Kev on the call? I think it would help if you could walk us through this a bit. I'm not sure clients have had time to get into this one too deeply.

Kevaundray Wedderburn: Yes, I am here. I think there's been quite a lot of conversations with regard to the retention windows, even in Glamsterdam. If clients haven't looked into it, then I'm okay with skipping it until the next ACDC. And then…

Barnabas Busa: Maybe we could just defer it for the next call and move on for the other EIPs.

Alex Stokes: Yeah. Okay. Okay, but then can we agree to take a look for the next call? So, everyone, you have a little… little homework. But sure, I'll defer this for today. Okay, next one up, then, is optional execution proofs 8025, and… Let's see, we have Ignacio and then Francesco here. Would either of you like to say something about this?

Ignacio Hagiopan: Yeah, sure. Well, we actually want to propose CFI in this. I know I've been talking about with many people around this EIP, And I think the most, Contentious thing is that it's an optional feature for the network. I don't know, we will have time, within 6 minutes to fully discuss this, but… Instead of me shilling about. DCIP, I would also prefer to hear from CL clients what they think about it, or which are the angles of the proposal that they might have more concerns, and maybe that's more useful.

Alex Stokes: Yeah, so we do only have a few minutes, but also, I think… Any other EIP? It's just gonna take a while. So we could start the conversation today if people want. But yeah, unless we can get to a decision in the next, yeah, 5 minutes, then we'll just defer this until next time. Then we'll pick up with the rest. On the next call. So, yeah, I guess any… any brief comments, for this, or… Lukasz, you can go ahead.

Łukasz Rozmej: Okay, I have 2 problems with the CIP. So to give a bit more context, I love the idea of execution proofs. I am working on a Nethermind guest client that would support creating execution proofs in zkVMs. We already have support for 3 different zkVMs, and currently I'm optimizing it, so just to give you the context. So, I love the whole concept, but I'm… I'm not sure if I can get behind, CFI-ing this. with 2 to be major problems. One problem is that historically, when we ship something in in the fork, it's ready for productional use. even if it's optional, this won't be actually secure enough due to, for example, gas repricing that will need to happen for this to actually be secure. So we'll ship something that we know that isn't secure enough, and that users shouldn't actually use it, so

I don't see the point of shipping it in the fork. That's one thing, right? So, we are giving mixed signals to the community. Okay, we ship something, but it's not really production ready, so this is… this is wrong to me, this is not what's… We should be putting into the the fork. And second problem is that I think with the current solution, unless it's changed, the, pairs of guest programs and zkVMs are kind of chosen by committee. So historically, anyone could write. protocol implementations of clients, and they could compete on their technical prowess, for example, security, stability, and technical prowess. Here, there will be some decision made up front, and some clients and VM pairs will be embedded into protocol. Which, okay, they can change later, but this is a process, so this kind of.

breaks the current, like, culture of creating Ethereum software that I have a problem with. So those are my two problems with the EIP. And I love execution proofs, so… Just, just, just saying that.

Alex Stokes: Okay. Yeah. Ignacio, let's just take, your comments, and we'll wrap up. Yeah, just to be clear here. We will pick this one back up. We will not make a decision today. We just are at time.

Ignacio Hagiopan: Yeah, I just wanted to touch on Lukasz's comments. I think many of his concerns are more related to mandatory proofs than to EIP-8025, which is optional proofs. EIP-8025 is not really committing to any kind of pairing of guest programs on zkVMs or enshrining any kind of proof system or anything like that. It's mainly about defining the specs and upstreaming this work into. a repository where we can settle a lot of work that we have done, that we know it is useful, and we can defer all this discussion about, okay, which guest programs, which zkVMs, and all that to mandatory proofs until we have more data, and we know what is safe. The main idea for us, on why we think EIP-8025 is important to

to be included in the specs is that it will de-risk a lot of analysis on how zkVMs behave on other protocol changes, such as PVD. Umm. If we don't do this, we have to maintain, like, a zkVM branch on the specs, PVT branch on the specs, we have to mix both, and this is… Increasingly inefficient, considering that we have limited resources also to work. on many other important things for Ethereum. So that's kind of a short answer to these points, but I'm happy to keep talking about this in the next call, if needed.

Łukasz Rozmej: So would you consider this an informational EIP? Basically, it's defining the spec, but not shipping anything.

Ignacio Hagiopan: Well, I already know if information on the EIPs means that will get merged into these specs. Maybe I'm not… Fully aware how precise the process is on this front.

Alex Stokes: Just to jump in here, we are at time. Are we okay just to hold this conversation until the next call? Okay. Okay. Lots of thumbs up. Okay. Cool. Then, yeah, thanks, everyone. We'll keep working through these EIPs on the Hegota scope, next time. And, yeah, again. Let's all keep an eye on Sepolia. The fork will happen in just a few days. So… Happy forking, and I'll see you next time. Thank you.

Transcript adapted from ethereum/pm, CC BY-SA 3.0.