All Core Devs - Consensus #155

Transcript

Alex Stokes: Okay, let's see, Josh, are you helping with the stream today.

Josh Davis: Yep ready when you are.

Alex Stokes: Yup, okay, let's go.

Josh Davis: You're alive.

Alex Stokes: Okay, thanks. Hello, everyone. This is Acdc, 1, 55. The agenda is here in the chat. It's issue 1434 on the Pm repo. So today we have a few things to switch on for Petra. a number of things for Fussaka. And yeah, let's just go ahead and get started. So with Petra, I'm not sure if there's any testnet updates worth covering. As we all know, Mainnet is coming up may 7.th And yeah, we had said previously, we would aim for client releases for Petro magnet next week. the 21st of April blog post a few days after. That. Is, everyone feeling good about this. Any issues client teams want to bring up with releases? Or do we all feel like we can make that in time?

Okay, I'll assume everyone's ready, because no one's chiming in otherwise. Oh, yeah, Mario.

Mario Vega: Yeah, maybe if if that was a question for Cl depths only. But I can give an update from testing and what we were doing on the El side. Basically, we've been writing a lot of new tests and just reviewing tests. But everything looks good so far, what we've been doing is that everything that we write or think about? We just run it against all clients, and if we find something we report it. But so far, it's looking good. And we are more confident that than previous weeks about the coverage. So yeah, just wanted to chime in to say that.

Alex Stokes: Cool thanks, one quick reminder. So we had tried to put in to place a little organization for the main net fork. Just in the event, we need any sort of instant response. So there's this document here that I linked again on the Pm repo. And essentially, it's just having point, people from each client team. Just so in the event, we need to get in touch with someone we know who that is. It would be great if you could add some contacts in the next few days on this document, just as a Pr. and yeah, so take a look at that. Otherwise any other pector stuff that we want to get into at the moment. I think people generally feel good about it

and are making progress with releases. So okay. If there are no other pector things, then let's turn to Fusaka. So with Usaka to kick us off. We have purdos with Devnet 6. Devnet 6 is live. Maybe Perry or someone would like to give an update just on how that's going.

Barnabas Busa: Yeah, previous agnostics have launched approximately a week ago. And we seem to be having some problems now, just like started a few epochs ago. It's basically a few clients are having some issues, especially Nimbus, to have issues. But they said that the Esi also seems to be struggling. So I haven't had too much time this week to that deep into it. but maybe some of the client teams can give an update.

Alex Stokes: Anyone have anything to share.

Barnabas Busa: I know that in, for example, for us, there was some block processing time issues. This is for peerless. Yeah.

Alex Stokes: Yeah. Okay, was this related to this all proof computation.

Roman: Not really it it just for unknown reasons. The block processing time jump sometimes even up to 40 seconds. Unclear. Why? Because none of the changes happened in in the live sync, so I expect their resource, exhaustion.

Alex Stokes: Okay? So if you look at the spec, there's a few open prs mainly around Apis. I don't know if there's any open questions to discuss on these at the moment. I know we touched on them, some on the breakout this week.

Saulius Grigaitis: There's check.

Alex Stokes: Okay? If not, then I assume everyone's busy with Petra. Which soon people will be focused on pure dos. And yeah, otherwise we'll focus on the open Prs and keep working towards Devnet. 6. One thing that did come up was this Bpo eip. and it proposes a configuration so that we can say. for example, at this epoch the ball parameter should look like this. and there was a question of exactly how this configuration looks. There was some conversation on discord. There's a few different suggestions. We touched on this during the breakout this week, and I thought we had agreed to essentially have a list of objects or records and Yaml, at least on the Cl. Side.

but did want to bring this up. Just so we can finalize the decision today. Did anyone have any issues with what we settled? Yeah, Gabe has a link here in or example here in the chat. So you would have the key. And then, yeah, just this list of the relevant data. Anyone have any problems with this? I think one thing in particular is like Yaml support per client. Just in the event that there's issues parsing this. For some reason everyone feel good about this.

Barnabas Busa: There's also some discussion about potentially having this in a separate file. I'm not sure what was the decision about that? Or do we just want to include this in the config.

Justin Traglia: I would just like to config or included in the config not a separate file I was, I take that suggestion back.

Barnabas Busa: Okay. So there was another discussion about how we could. How how could the user override these in case of an emergency override needing to happen because we're writing a list element seems like a weird way to do it.

Alex Stokes: Yeah, I would imagine. Well, yeah, I guess if you wanted to, you could just edit it yourself. But I would imagine then clients would just ship with new configs, so you would pull some new release. You could even just imagine providing the configuration and replacing just that.

Parithosh Jayanthi: I guess the question there is, if we expect a Ppo to be going badly and we want to emergency cancel it. Would we do so with the new client release? Or would we do so with the flag? I guess if it's with a flag, then we're talking about an override approach. And if it's with a new release, then yeah, it's a new config, and it doesn't really matter. Then.

Alex Stokes: Do go ahead. I'm not. Answer.

Dustin Brody: I want to question the premise. I don't want to spend too much time on this, because I know I've done this a bit in discord. The emergency release thing is not going to happen. I'm I'm going to stay that more or less on the record, I think, not as a prescriptive thing, but as a descriptive thing. the the coordinate. We couldn't get this coordinated for Holeski in time. A bunch of people on a single telegram group on a timescale of minutes, and if you put the time scales involved here, it's a lot of things that go wrong go wrong on the scale of minutes to hours, and then you go from there to what weeks, days, weeks, and at that point that's just not

that coordination can't happen. I'm sorry. Please stop. I'm sorry. I'll rephrase. I think that, allowing this fantasy again, I will use that word very deliberately of of an emergency release to guide the design of this in ways that compromise the design in general is, is misguided.

Alex Stokes: Do you have an alternative that you would prefer.

Dustin Brody: Well, what it means is that to the extent that including it in this, in the say, a pre-existing configuration, if the only issue there was that it doesn't allow for an emergency override to me. That's just like a non issue. So it doesn't really create another alternative as much as as it eliminates one of the putative reasons for preferring a separate file.

Alex Stokes: Yeah, I mean, the separate file bit is kind of a detail. It sounds like you're questioning the whole Bpo idea itself.

Dustin Brody: Well, that, too. I've started taking that a bit as a fait accompli at this point I'll be honest. But yeah, I'm not. I'm not particularly convinced about Bpos in this context, either. That's true.

Parithosh Jayanthi: Maybe one more clarifying parameter. I'm not expecting Bpo values to be chosen such that a past Bpo has failed, and we need to schedule a new one to reduce the blob count. But rather, let's say we go from 6 blobs to 9 blobs, and we see a degradation of 5%. And this is a maximum number we had expected, and we have another Bpo for scheduled for about 2 months from now that we have roughly some amount of time to cancel, said future Bpo. So this can be achieved with conflicts being shipped at different times, and you have plenty of time to react because any Bpo section chosen any value chosen needs to allow for enough

time to react as well as be fine grained enough to allow for monitoring to judge the next how the next Bpo. Could go. So that being said, Would you still oppose that being declared as an emergency? Because, yes, it is an emergency as in, we need to delay the future fork. But no, it isn't an emergency that you need to make a release today. It's about cancelling a future fork.

Dustin Brody: No, I would not categorize that an emergency. If if it's in the timeline of when releases are feasible to coordinate, then it's not an emergency by at least a definition. I would see.

Parithosh Jayanthi: Okay? So I would rephrase the earlier point. As this is not an emergency, but having the ability to either override or ship a new config. It sounds like the preference would be to just ship a new config, and we choose Bpo values such that we can always cancel the future one with ample warning.

Dustin Brody: Give. Given everything that would be something I can live with.

Alex Stokes: Okay. So circling back to this configuration, are we good with this? It sounds like, yeah, this structure here, and the standard config that we all have. In the event we need to change it. There would just be a new configuration that a user of a client would get in some way do we feel like we need to also have like a command line override. I mean that to me would be more this emergency situation. But it's like another code path to test. And yeah, it it would be tricky to coordinate Henrico.

Enrico Del Fante: Generally okay, is. The only thing that you want to point out is that adding that in the main configuration there is a slightly impact on the on the begin. Api spec endpoint that returns all the configuration. And we have this structured array. Then we we need to make sure that we render in Jazzon this Bpo schedule, and we don't break any Vc. That because Vc. Essentially is not. it's not interested in this information, or for some reason it may may not expect the edge as an object in the response, as a nested schedule. So yeah, we need to make sure that we don't break anything.

Alex Stokes: Yep, that makes sense.

Barnabas Busa: Just translate to Jason, anyway. So I don't see a problem here.

Enrico Del Fante: Yeah, I mean on on the Vc side, can talk about only only tech. I don't think there is any problem, but any any tooling that consumes that endpoint. I don't know how is designed and what are the assumptions there, so.

Barnabas Busa: Well, I mean, if we make a decision today about the structure, then it should give them plenty of time to deal with this later.

Alex Stokes: Yeah. And I mean, this is something that will up here in testing. I guess, like one issue is, if you know, some implementation treats users like unexpected keys and causes an error or something. But I I think we'll be okay. Cool. So we'll go with this format that gave player in the chat. We will put that in the config. Yaml. Yeah, Mark, we are.

Mark Mackey: Okay.

Alex Stokes: And no no cli, for now.

Mark Mackey: That is currently what is in the IP, or at least like very closely approximating it. The tricky thing is just like the config file is technically a yaml file, but we have never had anything that was like a nested array or anything like that. But that is valid. Yaml But client teams should watch out for that. I I do think it's worth doing it that way, because this may not be the only time that the consensus side has to specify a sort of array like object in the config. And the El side already does it regularly. So if we do have problems with that. It's it's worth fixing.

Alex Stokes: Yeah. And again, I think it will. I mean, this sort of thing will come up immediately in testing. So we should know Justin. Now, should we? Backfill? Didn't have an Electra limits? We need to do Electra, for sure. You mean like, include those in the Bpo schedule.

Justin Traglia: And the blob schedule. Yeah.

Alex Stokes: Why would we need to do that?

Justin Traglia: So we don't need Dinet. But we do need Electra. I believe. I mean, like, if we just want to use a like a get blob. I get Max Pops per block limit function like it'll need the electro blobs on it which we're using. And truly, at the beginning.

Alex Stokes: Yeah.

Justin Traglia: And.

Alex Stokes: Yeah, I was thinking about this is, it would just go live after Socca. So Electra would be in place and then slide up for Sokka. And sure maybe the there's like the same data in this in this list. But.

Justin Traglia: To be clear. I'm not suggesting that we change how like Alexa works. I'll explain it later.

Alex Stokes: Okay.

Barnabas Busa: Regarding testing it would maybe be a bit problematic then, because we could assume that we're starting with the app, or we can assume that we start from Electra. So then how would you specify that we are starting from the app, or we starting from Electra? If we just say next blobs per block is whatever. So I can see that feel. Then we might need to backfill all the way.

Alex Stokes: Because the current shared us. Devnets are on top of Deneb and not Electra.

Barnabas Busa: No, no, they are on top of Elektra. That like what's gonna be the 1st one, and then it's gonna be epoch 0 and the specific Xbox per block that we we might have more Bpo schedule in in the future. And we might have flu at epoch 0 eventually. And we're gonna have, whatever the next star will be at epoch 0. And then we can have a mismatch of mixed flops per block scheduling scheme.

Alex Stokes: Why would there be a mismatch that would sound like in configuration? Error like it should be fine. Just have like, yeah. Epoch. 0 is like the fuller set, and then you just go from there.

Justin Traglia: A slightly different question. Are we going to use the blob schedule for, like future hard forks? It might be what Barnabas is asking so like, for I don't know if we decide to raise the up on that in the future. After Bpo Forks.

Barnabas Busa: Yeah, like, do we want to touch anything else ever? Or is it only gonna be the Max blobs per block at that specific epoch.

Alex Stokes: This should be fine for Fusaka, and it could change in the future. I don't really see a reason why at the moment, but it could. Okay, cool. I think that's sorted. And that does kind of tie into the next point. So we have parados.net 6, and we should be looking towards Fusaka Devnet 0, especially as Pector goes live. That will be the next devnet to focus on. We talked about this, some on the breakout this week, and it sounds like there's agreement for for socket of net 0 just on the cl side to be pure dust. Mnet 6, and then also go ahead and include the Bpo eip.

So that would, you know, imply that's implemented and working. And we do have some like initial configuration and data for how we want the socket 0 to look like. I guess there's a few things here. I guess one, then, is like, Do we want to move this eip to Sfi. or do we want to handle that later? It's Eip 7, 8, 9, 2. I don't have a link handy, but it's there. and yeah, this is maybe administrative at this point. But it sounds like we are going ahead and scheduling this Bpo eip for inclusion. Should we just go ahead and do that formally?

Okay, Armas has a question no reason to do for sake of 0 if we don't have Eos? Yeah, the intent is to have some version of Uf ready for for soccer. Devnet 0. I don't know if we want to touch on that today. but I think we should aim for this to have 0 again with pure dos. Devnet 6 and vpo we had suggested on the breakout this week to aim for somewhere around May 20th for for socket dot 0. Does that timeline sound reasonable to everyone?

Barnabas Busa: I think the timeline is a bit more questionable at this point, and if we don't like, if we don't include the latest version of it, then I don't think we should do, and we should just do Bpo with. because there's no there's no reason to have an old version of the OS. Pushed on top of this this branch.

Alex Stokes: Yeah. I hear that I would think we try to get everything ready I don't know if Dan or any of persons here today. But this is something I guess we can discuss next week, if not today. And I do think we should push for this it'd be good to have a even if not completely stable, but a devnet 0 up as soon as possible. yeah. And sure, you know, if it looks like Uf isn't ready. Then we'll probably do what you're suggesting. Suggesting Barnabas. Yeah, Perry says, as far as he knows, the timelines should align. and no one seems to have any issues with this May 20th approximate date. So I think we should have that in the back of our minds.

Okay? And to be clear, it looks like there are enough comments in the chat to go ahead and sify Eip 7, 8, 9, 2. So I can go ahead and make that change later today to the Meta eip. And that tease us up to the next agenda item, which is the Cfi set for Fusaka. So to recap we currently have pure dos sfied, meaning it is shipping we just moved the Bpo eip to Sfi from Cfi, meaning the Bpo eip is shipping from there. There are a number of Cfi eips to discuss. We had touched on this last Acdc and yeah, essentially, just given the timing of different eips when they are proposed, and essentially having the deadline for Fussaka Cfi.

we wanted to revisit those today. so we should go ahead and make a final Cfi call perfect soccer today. And again from last call and looking at the Meta eip. the only real eip that stuck out today to discuss for Cfi. Is this eip? 7, 9, 1, 7. This is the proposal. Look ahead, Eip. There were a number of other ones that we essentially lean towards Dfi for Fusaka again, acknowledging that we essentially want to exclusively focus on pure dos and eof for this work. So given that context, let's touch on 7, 9, 1, 7. Would we like to Cfi it, or otherwise move to Dfi. On this call

Asgar says, Dfi. 7, 9, 1, 7, and Dfi the others? Okay, so we don't know.

Dima Gusakov: From here back. Yeah. So I just want to make a short note regarding 7, 6, 8, 8, yes, is usually so, or together with the mixed bytes team we are currently working on a like a detailed research on the actual effects and the actual impact of implementing this eap the research is aimed at understanding, who is currently using for 7, 8, 8, which is beacon root on execution layer, which is directly connected to 7, 7, 6, 8, 8, and the preliminary outcome is that currently Eigenlayer, Lido, and one more protocol which I cannot remember by heart is actively using this eap. And there is, like around 10 or more protocols who are currently working on

implementing for 7, 8, 8 into their protocols. And again, I want to point out that without 7, 7, 6, 8, 8, they all will have to do. Some sort of a maintenance should become State change which it most likely would in Fasaka. So just want to point out again that by including 7, 6, 8, 8 into Fusaka, we will save a lot of time and effort on the up layer for the app layer developers. And again, the the actual research, unfortunately, is not ready by today, but it will be published, I believe, this week.

Alex Stokes: Okay, thank you. Let's just circle back to that. because I do want to make a decision on 7, 9, 1 7, is anyone in favor or against Cfi? I would like to hear from clients. Frederick.

Radek: Hi, so yeah, I already wrote on discord some time ago that I am weekly against because of the, you know, not because the the vip itself is technically, you know, something's wrong with it. But because of the you know what we agree agreed on of how we are going to, you know, work from now on in terms of scheduling forks and including stuff. And I'm looking right now at teams diagram where there was a minus one. And N and N. Plus one, I can share it with you. It's in the all core magicians. And if you look at that, if you look at the 1st diagram from this post for fork, and we can propose eips between testnet and mainnet releases for the previous fork. So in that terms, it's perfectly fine, in my opinion, to include the cip, but I think we also agreed that we shouldn't include eips that are like not like

change something in the consensus if we don't have testnets that have been running with many clients, and they are working, and for the cip we had 0. And so that's why I am slightly against including the cip.

Alex Stokes: Right? Yeah. So I hear you with the point that. yeah, like, what we should be very careful to do is not include a bunch of vips into a fork without due diligence. We saw with Petra that that was problematic. So I don't think anyone wants to do that. I think at the same time, the way that we now have the setup of Pfi to Cfi. To Sfi it seems like Cfi. Is this like conditional approval that it's worth looking at in more depth, and that's where. Then we do the due diligence and then maybe just like round this out, like we wouldn't put this into. Say, if we saw nets until everything else has essentially been proved out to be stable, right? So

we would still focus on pure dos, and eof only when that's the case, would we then circle around to the Cfi side? And I'm not really making a general claim about the cip in particular. But that's the high level process. So I think it's helpful context. And yeah, okay, I think, taking the comments on the call and in the chats were like net neutral. There's like a number of weekly in favor weekly against.

Sean Anderson: So the lighthouse team were weakly in favor. I think it does introduce a feel to the Beacon State, where, like we wouldn't have any beacon state changes otherwise. So that is like a reason not to do it, but weekly and fear prototype.

Mark Mackey: Not to do it for other teams. I mean, we already have the infrastructure. But other teams may not necessarily have put in the boilerplate code to have changes to the Beacon state. So, and if that's like a huge amount of undertaking that would delay the fork, then we can understand that.

Barnabas Busa: How hard is it to implement this vip? Because if it's really just done under one day, and it could be included in the next subnet without any problem from every single cld. then it wouldn't like delay the fork, but if it takes like weeks and weeks of effort, then it should be not included.

Tim Beiko: And I don't think I would push back against including it in the next devnet until we have tiered as an Eof, even if it's a 1 day thing like, I think this is how we got screwed in Petra. We should make sure we have a stable thing that works and then decide if we want to add more. So obviously, how long it takes makes a difference. But I I think once we have academic 0, 0, we can look at the Cfi vips and decide, okay, which ones make sense to add the fuse. Academic one. But yeah, let's let's not include it already.

Barnabas Busa: I'm not saying to include it, I'm saying to keep it as Cfi, just not yeah. Fire it.

Lin Oshitani: Yeah, I'm interested in what like the Cfi thing they consider needs to be included. Because. like, I completely agree that pure desk is top priority like without that. like all roll ups based or not, based like on skill. but like being considering as in like, as long as it doesn't interfere or like with pure desk scheduling, we can consider it for inclusion. I think there'll be a good position, and I'm happy if there and yes, it's gonna be very like useful for be confirmations. It's a relatively small team. So yeah, introduce student people are. yeah, opposed to even considering it.

Alex Stokes: Okay, I think, given the input and the fact that this is only Cfi and not Sfi. it seems like it's okay to move ahead with Cfi for this today. Is that okay? With everyone.

Potuz: Elect.

Alex Stokes: Yeah.

Potuz: Oh, I'm not sure I I can't raise my hand. I'm driving middle of nowhere. so I just want to mention. I'm not sure because this was cutting off. But including this and testing this would be quite a big change in that. It is the only thing that changes the Beacon state when there was another eip that was mentioned, as if this was going to be something surely to happen in Fuzaka that we would change the Beacon state, but so far out of the eips that we're considering. Nothing touches the Beacon State. And I think the crucial question we should be asking ourselves now is, do we really want to change that structure just because of the cip?

Because of this feature? Do we want to change the beacon state.

Amir: Thankfully. Tell them poet is.

Mark Mackey: I suppose the answer to that question would depend on where other clients are in, in how prepared they are to change the beacon state.

Alex Stokes: Right. That sounds like it might be easier for some clients than others.

Dima Gusakov: Well given, even though we don't have such a process yet. Of consider like of specifying something for the hard fork after the next hard fork, and given the common bipartis, that and many others, that with the current scope of ssified Eaps there will be no changes to Beacon State. If we can agree, say. of sifying this eip for the Glamsterdam that might work. So if we 100% sure that there's no changes to beacon State Infosaka, which means that there's no issue to address, at least in this hard fork, and we can sfi now it for the next hard fork. I think it will solve solve the issue that might pop up should some changes to the State appear in Fusaka.

Alex Stokes: Right, and I guess this kind of gets to. I think Ongar was trying to prompt either Justin or Lynn like, how bad is it to hold off on the zip or the Procomm's use case. because it seems like that was the main use case that the cip would support.

Lin Oshitani: Yeah, I can give some context around the pre confirmation. So like pre confirmations like, without this cip, what would happen is that we would like. What we are discussing right now is basically having the oracle. Oh, a close to or like trusted oracle solution which would like make ensure that the lookout is available in the Avm. And there's which is like it will work. and we can have reconfirmations. But yeah, it's kind of a hacky solution, I would say, and awesome. They're not a you. And once we have the cip like, we'll have the look ahead completely available in the Evm. And a stable way which would remove all the need of hacks, and we'll really simplify

the protocol that we have.

Alex Stokes: Reddick.

Radek: Yeah. So I actually think I changed my position to slightly in favor. But I would just like to state that similarly to the attestation eip in the previous fork, which was supposed to be easy, but turned out to be huge. I don't expect this one to be as big. I hope it will actually be as simple as you know, the people who have already implemented it are saying, but what I think we should like agree on is that if we start working on it and start having definites for it, and it turns out that it actually is more involved than we initially thought, and you know there's this and that, and you know whatnot, etc. And we see that it's growing and growing. We should make a decision to roll back, and you know, not

continue, and you know, try to push it and try to to complete everything so that it's ready and just say, Okay, it. It turned out to be more complicated than we thought. Let's move back and schedule it for the for Amsterdam, and not try to push it for Fussaka.

Alex Stokes: Yeah, no, I think that makes a lot of sense. And that seems generally the same page that everyone's on. Matthew.

Matthew Keil: I definitely want to just verbally. Second, what Tim said, that we don't want to get ourselves into the same situation that we had with jamming things in. And even though this isn't a jam, we don't know the scope. Let's get what's on the current roadmap in. Get the devnets running, and then, if there's still time, we can always add stuff in.

Alex Stokes: Right? And so, yeah, I mean, at least, that's how I'm thinking about the use of Cfi here is it allows us to make this call later. Obviously, that means that there's like some initial due diligence. And if it becomes problematic in the way Radek and others are suggesting, then definitely, it would not be specified.

Matthew Keil: But I think the biggest thing is is to not take away dev velocity from the current development and the current feature set and just keep focus and keep keep scope small so that we're all going in the same direction. And we can make sure that we're gonna get the next work, both quickly and smoothly.

Alex Stokes: Yeah, I mean, that's why I like this pattern of basically only having sfi things on devnets only once, we feel good about those. And they're stable. Do we consider other things? Okay? So I think, taken all together, then it sounds like there is at least week support for Cfi and the cip. 7, 9, 1, 7. So let's go ahead and do that.

Mark Mackey: I also just wanted to point out, like one of the concerns of this vip was just that it might you know, burden epoch processing a little bit more because you have to calculate all the next epoch proposers at epoch processing time. But I did some measurements with lighthouse, and that doesn't appear to be a concern, even like lighthouse, even the naive implementation. I I hadn't used caches that we have, and the fact that we have Tree States makes the proposal calculation extra slow without those caches. But it was only making epoch processing about 2 to 3% slower. But I'll see with caches, and I think it may not be necessary in other clients that don't need tree States to use caches. So.

Alex Stokes: Okay, thanks. Yeah. So yeah, maybe just to summarize like week support to Cfi. So we'll go ahead and do that. Everyone is saying that essentially, at the 1st sign of any complications, we just essentially deify it for Fusaka. So we would not, Sfi. It would not move on to any devnets, and we would move forward. Okay, then we did have one other eip to touch on. Dimitri wanted to discuss 7, 6, 8, 8. And yeah, I mean, I think it's essentially the same conversation we just had for this eip just to be clear. This eip is about the stable containers. And the main thing is, it keeps these generalized indices in the proof part of Sse stable. Yeah.

we had touched on this last Acdc. And again, I think, given like scope considerations. And the fact that we do want to focus on paired us pretty exclusively. Yeah, essentially, there wasn't that much support to Cfi list. We're here. So anyone would anyone like to see if I it's or do we think we should not.

Dima Gusakov: I mean again rolling back to the previous comment. So if there's no changes to the state. there's no need for this eap. which is great. If the previous one would be included, I would hide the recommend, including, like both of them. So the 7 9 whatever, and this one, if not, then it's like it's fine to to keep it for later.

Alex Stokes: Yeah. I mean, yeah. So the obvious issue is, we have this like, kitchen sink situation where we're like, okay, we put this one. Then we need this other one, and then you know it. Cascades, which you know, I think everyone is very aligned that we don't want to add a bunch of vips to Visaco. Yeah, so yeah, just kind of summarizing the chat here. Like, I think, following the previous argumentation, we just had like, it would make sense to Cfi. But I think then it's kind of as I'm saying. it starts to feel worse if we have all these things that could potentially go in.

Dima Gusakov: So just again, just just one suggestion from my side. If we Cfi like the previous 1, 7, 9 1 7, then we also did. Cfi. 7, 6, 8, 8. If we not, then let's Dfi both of them. and then we are good.

Alex Stokes: Okay. So does anyone disagree with this approach that we should see if I, both or neither.

Sean Anderson: I I disagree. I think we should just see if I the proposed look ahead, and not 7, 6, 8, 8. I just think it's a simpler change. And I think it's yeah valuable.

Radek: If the proposal look ahead, one has benefits without the other one, then let's include just one. If it doesn't have any benefits without the other one. Let's not include any of them.

Enrico Del Fante: Yeah, as far as I understood. it, does have benefits on one side, but then creates problem on other sides. So it's not the same use case.

Mark Mackey: My my understanding is that even if we include 7, 9, when ain't the the proposal? Look at Eip that we're not going to break proofs for the Beacon State, because we're not crossing a power of 2 boundary. and if that's the case, then we don't. There's not like a huge motivation to put 7, 6, 8, 8 in this fork, because, no matter what there needs to be, at least one time that the app layer is gonna need to update their proofs when we include stable containers hopefully, exactly one time. My hope is that we can include stable containers when we make a change to the Bea state that breaks proofs so that they only ever have to do this one more time.

But right now my understanding is that even if we include 7, 9, 1, 7, that we're not going to break the proofs. And so this is going to be the exact same amount of work for the app layer, whether we include 7, 6, 8, 8, or not in this form. Well, actually. there, there they would have to update their proof sooner if we included it in this fork. But either way it needs to be at least once more and hopefully, exactly once more.

Alex Stokes: Okay. Anyone want to speak strongly to coupling them.

Enrico Del Fante: So I if I'm if we are sure that introducing that doesn't break anything on the proof side makes sense to separate them. but from from from from technical perspective. As I also said, you wrote, we are kind of okay to bundle them, because we have already oh. an implementation of 7, 6, 8, 8. But problem is, I don't know if other clients ever have everything already for 7, 8, 8, 10, 7, 6, 8.

Alex Stokes: Yeah.

Enrico Del Fante: Maybe delays for other reasons. Fork.

Alex Stokes: Yeah, my understanding is, there's provisional support across various as the implementations. But this is something that is like very low layer and touches. Yeah. Oh, it only touches Sz code. But that's used as like a foundational layer for many things. So okay, yeah, Matt.

Matthew Keil: So I think, from a broader ecosystem perspective. And I think this is something that really we should reflect on is we want to get to faster forks. We want to get to more regular forks, and there's nothing that stops us from just getting the small feature set that's nearly ready out now and then in 3 months. We do those 2, you know, if we, if we can get to this fast iteration of forks and really get ourselves into that mindset. All of these eips are much easier to get included. and maybe as a trial, we just get this one out quickly and just keep it limited, and then that might set a precedence going forward.

Dima Gusakov: Yeah, that that's a very good comment. But again, what we should keep in mind is that we, if we move to a faster, hard works, and if we do not have stable containers, then each and every fast hard work would require this shitty maintenance, which is a huge pain in the ass. So if we really want to move, to have to fast hard works, we also should think about like not introducing complications and hurdles for applications. So I fully agree that if in this hard work, if Infosaka, there's no changes to be considered, no changes to proofs, it's perfectly fine, then we include stable containers into the next hard fork, and then we can move like at any pace we want, because at least this part will be solved. But if we will not solve this part, and we will just transition to a fast, hard forks, and then, for example, each and every of them, or some of them will change the way. How proofs work

it would create like enormous pain for the applications that's also important to keep in mind. So it's not just about being fast on the core side, but it's also thinking about applications and making it. not creating additional complications for them. With this increased speed of hard forks, but in general I'm I'm fully for the increased speed of Hard Fork.

Alex Stokes: Frederick.

Radek: Yeah. So if I understand math correctly. This this proposal was, you know, we're working on pure das, we're working on some other small eaps. These other eips are ready. We can ship them in maybe 3 months. And I wanted to push back a little on that from engineering perspective. Because if we are working on pure das as the main eap, we are slowly merging stuff into our, you know, core code modifying sometimes very core functions and a lot of changes. And then, even if you have these other eips ready, then how do we? How do we release our clients? We would have to roll back all the you know. For example, peer does call so it doesn't interfere, and that it breaks nothing or maintain forks for every eip, and then somehow merge them together. It would be a nightmare, in my opinion, so I don't think this is something realistic.

Matthew Keil: That's exactly what I'm saying, though, is like right now, we're so focused on the big 2 like, really, it's pure das and eof on both sides. And anything that gets in the way of that will take away development velocity from us, actually getting those features 100% across the line. And that's that's exactly what I'm talking about. Radek, like. If we stay laser focused and make sure that we're all aligned towards those goals. we can get it done quickly. It might only be a few months before we're ready for the F. Fork, and then it could possibly be a few months for the G. Fork after that, but I think limiting the scope so that we're all moving in alignment towards each one of these forks, I think, is critical in order to be moving, moving the ecosystem forward as whole.

It's also more predictable for all the consumers, and I and I also agree with stable containers critical. But again, like, we already have the development velocity of where we're going for now. And you just you just have to choose what's what's the priority.

Radek: Okay. I apologize. I misunderstood you. Sorry.

Alex Stokes: Okay. So then, following the discussion. it sounds like 7, 9, 1, 7 won't impact the proofs. So then we lean towards, not Cfi and 7, 6, 8, 8, because there just will be no change. We can handle it in a future fork. So then we'd Cfi 7, 9, 1, 7, and yeah, basically, defi everything else sounds good. Okay, thank you. Everyone. Okay. So then, yeah, the Fusaka Vip set should be sorted. And there was one more thing on the agenda. And yeah, I guess. Is there anything else on Fusaka? This last point was around the builder Apis and the Med workflow?

It's something I did want to bring up. But yeah, I guess before that, any other for soccer comments. okay, so then, yeah, this last thing. this came up when we were working on the builder Apis for Fusaka. I believe. I think it was Francis who originally made the Pr, let me just double check. Yeah, so essentially, we have the builder Apis, and we are updating them for for Fussaka, where the main change was, I think, the cell proofs but either way, that was not the issue the issue was that jimmy, then was looking at this and raised the question, you know what happens as we're thinking about this Api in terms of very high blob counts right? So today, there's like a relatively small number of bobs.

Even with Fussaka, we could get to like quite a large number. And the question, then, is essentially the scalability of this Api. So how this has worked since the merge is that if I choose to use web boost, I, as a proposer, give my signature to the relay, and I get back the execution payload with the Neb, we added the blobs. So then it makes sense to then also add the blobs to this Api as well. And now the question is, as we increase the blog count. What happens? This is potentially an issue, because it's a synchronous Api so you would again, as a proposer, you would call the relay and get back the execution payload and all these blobs. And I think it was something that like.

say, there's 72 blobs which is potentially a balance for Visaka. I think it was something like 10 MB of data in the response. The concern is, you know, if I'm using my boost, I might also be like a relatively under resourced mode. And so now the question is like, is this even valuable, or the right way to think about this? And there's a number of things to do here. or that could be done. So one of them is a pretty radical change where we just actually have. We don't have this Api at all where there's no response. What this means is that the the relay itself is entirely responsible for gossiping the block and blobs

on their end. We could leave the status quo, where again the relay just returns all the data to the proposer, who then also gossips the data on their end. There's a sort of middle ground where you return the payload to the proposer, and then we have some other way to distribute bobs that could be sort of an asynchronous Api with the relay between the proposer. Also, someone brought up the point. I get blobs, and you could imagine that you might not even need to get the blobs from the relay point being there's a concern about this Api. There's a couple of things to do here. And I wanted to get feedback on different these different ideas.

Does anyone have any initial response or reaction? Or also questions. does anyone feel like we need to change the Api. because that was the the original concern that basically, it would be too much data for a proposer to download in time.

Barnabas Busa: It is too much data.

Alex Stokes: Okay. Parents.

Terence Tsao: I mean, this is also like an issue today with regarding to time out right, because relay will time out or will apply some delay before returning. The data. And typically client side has this time I thought, time out threshold. So it's a little confusing sometimes when you see, like an error from a relayer saying that Or seeing some error on the valid client saying that we failed to propose a block because of relayer, didn't return the block on time, and it's a scary log. But if you look at beacon blocks forward, your block is actually proposed. It's actually released by the relay on time and stuff. And this happens today quite frequently, and then it's not nice we should fix it. And I think this is kind of we can probably like kill, like 2 birds with one stone here like this, will also resolve that.

Alex Stokes: And to be clear. Your suggestion is just to return. Nothing.

Terence Tsao: I mean, I don't have a good answer. I need to study this problem more. I think you return something, but not like. But don't rely on proposer to like gossip, the blog kind of if if that makes sense. Yeah, I need to think about this more.

Alex Stokes: Okay. Yeah.

Terence Tsao: I mean, that's.

Alex Stokes: That does makes sense. Yeah, okay. So I'm at least hearing. We think we should revisit this Api for Fusaka. which might be enough for today. I've reached out to a number of different builders and relays to get their perspective as well. They're kind of in progress of reviewing this? Yeah. Anyone feel like we should leave it alone. Okay, just going off the chat here. It seems like people generally think we should do something. There's a question. Let's see, would this impact the trust assumptions based by pure dos? If we have a handful of relays?

Yeah, I mean, the relays would be responsible for getting the data out as well right? Because otherwise builders wouldn't use them. So short answer is, No. okay. That was helpful. I'll probably well, I will keep getting input from different relays and builders. And yeah, that will end up. probably with some kind of diff to this pr. and we can move forward from there. Let's see, I believe that was everything on the agenda. So yeah. any closing comments. Otherwise we'll wrap up for the day. Okay, then, thank you, everyone. I'll see you next time.

Mario Vega: By, the.

Ansgar Dietrichs: Thank you. Goodbye.

Dankrad Feist: I know.

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