All Core Devs - Consensus #160

Transcript

Alex Stokes: Okay, Josh, if you're helping with the stream, I'm ready to go when you are.

Josh Davis: Cool you are, live.

Alex Stokes: Okay, everyone. Welcome to Acdc, number 160. I'll drop the agenda here in the chat. It's Pm, issue 1598. And yeah, I guess really quickly, thanks again to Onsbar for falling in last time I was away. And yeah, still getting caught up on some things while I was out. But yeah, let's go ahead and get into it. So 1st off, I think this should be short, so I just wanted to go ahead and knock it out perry wanted to bring up Cl releases with updated gas limit values.

Parithosh Jayanthi: Yeah. So we've made a blog post and done the analyses as well as ship the fixes on the El side for updated gas limits. The updated gas limit recommendation, at least, according to most, Els is 45 million however, the Cl also sets the gas limit. If you're using the Meb workflow. and I know some clients have already started making releases with with the default gas limit increased, and I wanted to know if there's any client that doesn't plan on doing so in the near short term. Okay, I guess that means all the Cls will have it in the in in either their current release or the next release right.

Alex Stokes: Yeah, do we want to set some kind of date as a deadline? Not necessarily to like, accelerate releases, but more. Just so people would know then to update when it's ready.

Parithosh Jayanthi: Yeah, I'm not sure when clients plan on making their releases. I know the lighthouse just made theirs yesterday or today.

Alex Stokes: Yeah. I guess more like we could say, Okay, this will be ready by the end of the month, and then we can then go and coordinate with everyone else to actually update. Okay, I guess this is also something we can just keep bringing up on Acd until it's live. Okay, yeah, there's a bunch of comments in the chat here around release schedules. So it looks like most people have it pretty soon. Here, cool. Thank you. Okay. So now let's get into Fusaka. So 1st off, I wanted to start with the status update on Pisaka Devnet 2 I've been checking pretty much every day this week, and it was getting better and better by the day. Are there any open issues? We're still aware of that we should address right now.

Barnabas Busa: Yes, loadstar had some p. 2 p. Bug, that they might want to give an update on.

Matthew Keil: So we identified some issues appearing with Nimbus. They did a good. Oh, can you hear me? Okay.

Alex Stokes: Yeah, you're good, I think, somehow someone stopped the recording. But you're good.

Matthew Keil: Sorry. So we were having some issues with the protocol negotiation. We have on our side as well having a problem, but it only seems to be buggy with Nimbus and there was a lot of churn because we were disconnecting and connecting and disconnecting and connecting and I think there's some other issues as well with some of the other clients doing requested columns getting empty arrays back, which we also were finding. So there's a few things. But Agnes has done a good job of responding to everything.

Alex Stokes: Okay, cool. So yeah, I mean, I guess we'll just keep debugging all of that. The proposals were like much spottier earlier in the week. They look pretty good now just looking at it looks like there's boot no to one which I'm not sure. Why, that's a note here, but it is otherwise, yeah, proposals look pretty good. Participation is only around like 87%. Let's say hopefully, that could get a bit higher.

Barnabas Busa: To.

Alex Stokes: Bye.

Barnabas Busa: Some of the super nodes had some memory issues that tech. We had identified the bug in their code, and it should lead to less. Om issues. So also, I think Glostar have some memory issues and grinding as well only on this product. So this issue seems to be only be presented during the super nodes.

Alex Stokes: Alright. That's helpful. Context. Okay? So then, yeah, it sounds like there are a number of issues, but essentially people on top of them. And we'll just get those resolved. So anything else on Devnet 2. I assume we want to get Devnet to a bit in a more healthy state before thinking about Devnet 3. But that's the next topic.

Barnabas Busa: Yeah, so definitely, 2 will probably run till the end of next week, and then we can probably think about launching Devnet 3 around the 21st or 20 second of July.

Alex Stokes: Okay. cool. If we're good on Devnet 2, then then let's go ahead and move to Devnet 3. There are a few things here. So yeah. Again. I was trying to catch up from the last call. It sounds like the core pierdos. Things are fairly stable. Dare I even say a spec freeze from there, though a few other things have come up on Devnet 3 actually let me grab. Let's see, I'm trying to grab the devnet through specs. Just so people have them handy. I'll put them there. Just yeah. Thank you. Just in case people want to refer to them here. So either way, a few things just from the agenda right now. So there was a comment from Ben here who wanted to ask about some El eips clear 0. And the transaction gas cap changes.

Or, yeah, respond, okay, yeah, I don't know. Yeah, I did not. But.

Ben Adams: I I just wanted to confirm they were in devnet 3, because we discussed in an old all testing. But yeah, it didn't seem like it was a hard confirm, that was all.

Alex Stokes: Okay? And to be clear, I think it is a hard confirm. Maybe someone else can help confirm my heart. Confirm. Yeah, there's a comment here that I linked from Barnabas that essentially says this cool. Okay. So then we can get back to some Cl things. So I guess the 1st one to kick us off here on this list would be a proposal to change get blobs so essentially over the last few weeks we changed the semantics of give blobs v. 2, so that it allows what we're calling partial responses role here has a proposal to basically revert back the v. 2 semantics and then move this partial idea. And to A. V. 3 real. Would you like to say anything else about this.

Raúl Kripalani: Yeah, I think the operative point is that the way that this v. 2 spec is currently worded in main, it does not guarantee that Els are gonna be implementing partial responses now for for Fusaka, which means that we're setting ourselves up for more coordination later. And basically what we're doing here is making the support mandatory by moving it to a v. 3. That that Els would implement. But the Cl. Would not use until a little bit later before Glamsterdam, between Fussaka and Glamsterdam. So the idea is that we're working on a set of gossip sub changes that will enable partial dissemination of columns at the cell level and cell level reconciliation. And for that we need access to partial blobs, and we can roll out. The idea is to roll out this optimization

without a fork. Because it's set up as a as a gossip sub extension which is optional. So the idea would be that at that point. That's when the Cl would start consuming v, 3 to to get partial responses. But we don't wanna rehash this whole topic, then, so that's why this this proposal has been made.

Alex Stokes: Yeah, the the goal makes sense. I guess another option here. So I think the way I understand it is that v, 2 right now is essentially May, and, like canonical spec language, as in like yells, may provide partial responses, and you want it to be a must. So we could just update the V 2 to say that rather than add a v. 2.

Raúl Kripalani: Yeah, but but the but the trade off we're trying to hit here is that the the Cl is not actually gonna utilize partial responses now. So we don't want to be incurring in the survey cost of actually delivering them. So that's why we constrain v. 2 to be all or nothing, and v. 3 would be the one with partial responses. That's clearly signal that there is a behavior change between one and the other. Right now, the current interface does not make any of this exclusive.

Alex Stokes: Right? Interesting. I mean, I guess even another option here is just leave the current v, 2 alone, and just add v, 3. That's mandatory. But yeah, I would want to hear from steel clients if they have a view on this.

Dustin Brody: Yeah. So for for Nimbus the all or nothing was was pretty good, and the partial responses are not that useful? And and the thing is, I don't think they ever were claimed to be in the absence of a full ecosystem support. That's a full and tested and etc. So I I would say, if and I would actually agree with Raul's general points about the lack of clarity, about what is and is not supported by the Els at any given point as well, makes this kind of a low roi thing in general to implement so. And at this late date, and and for saka.

Alex Stokes: Yeah, I mean, the idea is, it will be useful, and it lets us do some things to help without a hard work. So this is kind of like, team us up. Yeah, launch to then do something better before the Amsterdam.

Raúl Kripalani: And just to just to be.

Alex Stokes: Like, yeah.

Raúl Kripalani: Alright, just just to just to add a point there. We think that the lift the implementation lift is really low. Because v. 1 was anyway returning partial responses. So I believe the code parts exist to rehash this logic in in Els, and in fact implemented this in a in a matter of minutes. So this, this would really help for the optimizations that we're planning and we're testing because we do. We do expect to consume partial responses before Glamsterdam. and, like the the whole point, is to alleviate, to to avoid any extra coordination at that point in time.

Alex Stokes: Yeah, I mean, are people. Okay? Then, reverting the V 2 changes. Cause, I think, if so, then we just do that, then, yeah, we do what this Pr is proposing, and one thing is like. well, we'd still ideally want to get v. 3 into Fusaka but it could be somewhat of an optional thing.

Dustin Brody: Barnabas posted on the issue for this call. That there would be no Fusaka devnet. for if so, I would say, that's, let's say, an extremely aggressive schedule for introducing a a core engine. Api change.

Alex Stokes: Yeah, I would.

Barnabas Busa: It's an optional change, right?

Alex Stokes: Yeah, well. it's better if it's not optional, like ideally like the the reason we want in Fusaka. So we know that everyone has it after Fusaka, like as of Fusaka on Mainnet. so ideally it's done. But it wouldn't be anything blocking like core R. And D as we go to may not. So it's something that could be done, you know, over, say, the next couple of months. and then, in terms of Dustin's point about this being a port change like it's, you know, if you've implemented the latest v. 2, it's just renaming that to v. 3 and then restoring the other. You know the original logic is v. 2, so it doesn't seem like that much.

I don't know if there was a commentary about a Boolean flag, and v. 2. I don't know if we want to reopen that part of the design space.

Raúl Kripalani: I mean that that was the original proposal. But I think it was it was rejected back then.

Alex Stokes: Okay, that one's just that. Okay.

Raúl Kripalani: Yeah.

Alex Stokes: Fair enough.

Raúl Kripalani: I mean, the whole point is that v. 2, as it's currently worded does not even like it has. The May is extremely lax. So nobody is able to tell from the outside what the el is actually gonna do, which is bad, especially when we have an exchange capability. Sorry. A a a capability, negotiation or exchange mechanism, we should just be using it. So that's why v, 3 seems to seems to be the right approach. And I think the point here is that is it pretty easy to implement it's not gonna be in the critical path for Fusaka right now. We can still test it. But it's not actually gonna be utilized by Fusaka right now. But if if Els would just el teams would just go and implement it. I think it would save them extra overhead in the future. When this is actually gonna be needed.

Alex Stokes: Yeah. would it be easier just to again change v. 2, so that it's must like the the partial responses are mandated.

Raúl Kripalani: So the the problem with that is that we wouldn't right now we wouldn't be using those partial responses. So would be incurring. Yeah, you're worried about. And that was why that solution was deemed. That's why the optionality was included.

Alex Stokes: Okay? Oh. no one's saying no, except for the fact that it just is changing the spec. And yeah, I was just gonna add a little more thrash kind of late in the process. but that being said, I think it will give us pretty good gains, at least, you know, set us up for that with cell level messaging even before Glamsterdam. So yeah, Barnabas, ask overhead on the Cl side. I think it's it would essentially just be adding this new endpoint to be able to call v. 3. And then from there it's more a question of well, I think the limitation is bigger on the Yale side.

Barnabas Busa: Well, we not gonna be able to test it unless we do an actual partial response right?

Alex Stokes: Yeah. But I mean, this is something we can test. Whenever are there any El Devs here who have an opinion.

Marius van der Wijden: Since I've implemented it in in get I I do have an opinion it's is very easy to implement and kind of the like. We kind of spec the engine. IP Api this way, so that we allow for these kind of soft forks and and changes to the engine in between forks. So I don't. Yeah, I think this like, there's not much that we need to test there. And basically the testing can happen like El only the only thing that we that we really need to test in a in a definite stand like, once we have set up a messaging, but we would need to test that anyway. So.

hey, I don't know. This kind of sets us up to do cell level messaging before before Glamsterdam. In the software, which I think is very easy very good.

Alex Stokes: Yeah. So yeah, I mean, I think the only real downside then is just changing the spec. But that being said the way I was thinking about it is, I was at least expecting there to be like some minor changes today. So in that case I think I would lean towards go ahead, going ahead and making this change. Anyone feel we really should not do this.

Barnabas Busa: I just don't understand. Why do we have to have this? By Fussaka? If nobody is gonna implement it, nobody is. Gonna have a way to call it and know, and we would not have a way to test it like, why can't you just call this for grand and basically just go ship it v. 2, and be able to test that, and then we will scope this for.

Raúl Kripalani: Yeah. So the yeah. So the changes, the changes that we're planning do not require a fork. So we don't. We want to roll out these changes between Fussaka and Glamsterdam, and we think they're gonna be necessary to push the Bpo confidently over specific levels. So that's why we don't. We don't wanna wait for Glam Stam. And we want to introduce that change. Now. I mean, technically speaking, as as Marius said, the engine Api is prepared to introduce these capabilities at any point in time. But we just don't have a process for that. We always discuss the engine Api and the context of specific forks. And the evolution is done in the context of specific forks. So we just don't have a process to modify it export. That's why we kind of like forcing to get this trying to rally, to get it into a center.

Alex Stokes: Yeah, okay, I don't know if I want to open this can of worms. But we will have a process, because, assuming we do sort of like a staged Bpo rollout. We essentially would have another opportunity with, say, the second Bpo deployment to do this. but then, at that point it's no longer sort of this pure Vpo idea, and it becomes more just another hard fork. But that would give people more time. Flc, us, can we just roll back to partial responses. So I believe that's what we have right now with V, 2.

Raúl Kripalani: No, so partial, partial. So basically partial responses in v. 2, right, like original original V, 2, were not supported. It was all or nothing. Then what's currently in master is very relaxed, and it basically introduce at the May may return partial responses. Maybe not. Maybe it's on or nothing. Nobody knows. and B. 3, and and the current spec change. What proposes is to restore v. 2 to all or nothing, and to move partial responses to v. 3.

Alex Stokes: Right.

Raúl Kripalani: So I, yeah. So I'm not. I'm not sure what else have implemented so far. Maybe that's a good question. If they've already implemented the May version that's sitting on Main right now. I don't know. Maybe they can give us some signal.

Roman: As of there. Now, too, we have or or not in responses.

Raúl Kripalani: Got it is that the case for the rest of yields.

Marius van der Wijden: Yeah, it's the same for us.

Alex Stokes: Okay, so that's compatible with our rules proposing here. Basically, we just leave that as v, 2, and then have a v 3 for this.

Raúl Kripalani: Exactly.

Alex Stokes: And yeah, like, I think we should stretch to ship it in Frisaka. But again, it can be a lower priority, I would say. and if you know, as we get closer to test nets, it becomes a case that this isn't looking like we have time for it. Then we can cross that bridge when I get there. Yeah, Barnabas. So if it's in Fusaka, then we know everyone updates at the Hard Fork, and so we can rely on it. If we don't do this, then we're kind of back in the status quo where it's like the El. Maybe has it? Maybe doesn't. It just gives us stronger confidence that we know we can rely on this and use it productively.

Yeah, I mean, yes, like, this thing would be tested before it goes to Mainnet.

Marius van der Wijden: It's the testing for this.

Alex Stokes: Don't know.

Marius van der Wijden: The testing for this is literally like 2 lines. I I don't. I don't understand why. where people are like, basically we like we have the testing for this already. We're we're testing it with we can test it with eels and and hive like the there's nothing to be tested there. It's basically, does this method return partial responses or not? And then we have the same test corpus that we have for v. 2 as well.

Alex Stokes: Yeah, I don't think the testing load is that heavy and also dustin to your point, I think, Perry responded. But you know the idea is essentially of Devnet 3. Be the like frozen specs. From there there will be many Dev notes, I expect, perhaps more ephemerable to test like different load and block counts. And all this. So it's not that there's only devnet 3 full stop. Okay. it sounds like we should go ahead and merge in this change from role. And yeah, so v, 2 will be as is I think, as people have implemented, we'd revert the changes to the repo there and then just have this functionality in this new v, 3. So let's go ahead and do that.

Okay. let me find the agenda. Okay, another spec issue, or at least open points with Devnet 3 we have. Let me just grab this draft Pr here. This is not necessarily a or point to peer to us, but it's adjacent, and something that I think we want to do. So we should go ahead and get this. Get this moving. We had discussed this on a previous call, I forget which one. But basically, there was this proposal to change the builder Api endpoint of get payload so that it actually just returns nothing right now. The proposer gives the sign blinded beacon block to say the relay, the relay returns. Then the unblinded data. Here the execution payload and the blobs.

The issue is as we scale the bobs. This now becomes like a lot of data potentially over this, like one synchronous endpoint. And yeah, we expect that will cause issues. So there's a number of things to do here or like things that could be done. The leading solution at the time was, Yeah, this is an issue, and we should do something. And I think there were generally as weak support for just changing this endpoint so that it returns nothing at all. And just having this responsibility beyond the relay from there. Yeah, there's like things you could imagine the relays do in terms of the blobs, and how they expose the blobs to proposers and anyone else who wants them.

But I think what's simplest to move forward here is just actually make this change as given in the Pr which drops the return data from this Api endpoint. So does anyone have any thoughts on this or questions to follow up to the idea? Okay, thumbs up from Terrence, and I'll assume that's a thumbs up on dropping their the return. Okay, okay, cool scene. A lot of thumbs up. So let's do that. Cool. That was easy. I guess. One question. Since we're here like there is a design space, or you can imagine relays do expose the bobs almost as like a archival service or something like this. Does anyone feel like that's interesting or valuable?

The reason I'm asking is, this, is again kind of a separate conversation to have with the relays. But it's something I could bring up with them. So I'm just wondering if anyone has any thoughts either way on this right now. when can we test it? I think we can get this implemented pretty quickly. It's a pretty straightforward change. although I guess cl clients would need to also update.

Terence Tsao: This we would require the builder and the relayer changes on the def net right? And I think.

Alex Stokes: It's really, there's 30 relay. Yeah.

Terence Tsao: Okay. And I mean, we can test this on kurtosis as well. I think.

Barnabas Busa: Yeah, yeah, exactly. Yeah. The main issue right now is our builder. So our builder is still using an older version of rest. With some dependency issues that have not been updated from fleshbox. We are working on it, and hopefully, we'll have something next week.

Alex Stokes: Very cool. Let's see. So that was that, okay, yeah. We touched then on a potential launch date for Devnet 3 Barnabas. I think you said something like 2 weeks from now. maybe like, yeah, that would go the 21.st Okay. that sounds good. And then otherwise, yeah, the last time. Yeah, let's just say before I was out we were talking quite a bit about Bpos and how to implement them with this fork digest change also about your custody. There are like a number of things here at pure dos. I just wanted to check in like, are we feeling good about these things. Now. I think we've mostly handled all the spec issues in the devnet to spec. So then, it's just a question of implementation.

But yeah, any anything to surface here before we move forward. Okay, cool. Then I did want to briefly touch from there. Yeah, the plan on actually getting this to Mainnet. So I'll call out this blog post from Sigma Prime that I thought was really good. So Jimmy wrote this blog post here with their view on essentially getting peer dos to Mainnet this year. I think, like some key information, here would be this planning section towards the end, where basically it says something like a mid October Mainnet launch. That implies, then test nuts something like Heleshke in September something like Sepholia in August. which doesn't give us much time to get to that point.

The so that's sort of the second half. And the 1st half, then, is where we are today, where we basically would then say, Okay, let's go ahead and iron out any issues with Devnet 2. We'd have Devnet 3 stable or not. Stables. Wrong word. But we'd have devnet 3, you know, defined, let's say. hopefully, there aren't too many things in terms of implementation difficulties from 2 to 3, and we could then hope that Devnet 3 is like this happy path, stable paradise implementation. From there we want to turn to do. You know, many different sorts of testing around, you know, actually loaded these things at different blob counts testing different vpo parameters. How that affects syncing. And yeah, all the different things that we have. So

I think the main point for today is just to get this sort of rough schedule in everyone's minds. Yeah. I did want to touch on the Bpo bit here. But I wonder if anyone has any comments about what I've said so far. Okay, Justin says he likes to schedule. Very good. Yeah. I would kind of consider this to be a strong man at the moment. But I think it's a nice, strong man. I think it's something we should reach for Perry brings up. We need at least a non finality network. Right? Yeah, exactly. So, yeah, yeah, non finality. Different failure. Scenarios on networks. Syncing is another big feature set to to verify. But then from there we can decide these different Bpo parameters.

and then I guess that tease us up to the next point that I wanted to talk about, which is, yeah. Thinking about how we actually want to do this. I think there was some discussion either on last Acdc. Or even Acd this week around what we'd actually want here. It seems like, from what I could catch up on that. There's pretty broad support for having a more conservative rollout with Fusaka, where basically, we just schedule like maybe one substantial increase at launch. Then that would imply we have a Bpo update early next year to get us to like a higher number. Do people generally feel good about this? The alternative would be honestly a more aggressive option where we just try to have like more. Pbo scheduled with Osaka.

Yeah. Okay, reading the chat here, people are talking about syncing. So yeah, I'm not trying to get too ahead of ourselves, but more just pipelining all the things we need to do to get to the sock on Maine sounds great.

Ansgar Dietrichs: Yeah, just just to very briefly, kind of recap from from, like, I think 2 weeks ago on Acdc, we just briefly touched on different potential variations of this. So basically like. would we want Fussaka directly to bump up blobs or basically have one or several Bpos bundled with it. And then, if we have Bpos bundled with it, basically, there's the idea to either do something like very quick after the fork, so like, say, a week after the fork, or something that just does a bump or something that's a bit farther away, so that we could already collect some data before the bump. And then, after the bump. so say, like a month after, or we could do both, so, for example, say, like Fusac itself, rolls out without any changes in throughput just switch over to Pdas. Then one week later, we have a small 1st kind of increase in throughput and then like another month later. So we basically get to whatever we think is the actual safe limit. And that way, we would basically like be able to monitor the network at different levels. So that's kind of like, I think, roughly, the design space kind of like 0, 1 or 2

bundled Bpos, together with the Fusaka rollout. If I remember from 2 weeks ago.

Alex Stokes: Yeah, that makes sense. And I guess you know, the point I want to kind of get to is like, if we had one. if we. If we have the strategy that we want for main ads, then we can kind of include that in like Devnet 3, you know, sort of the like. there'll be almost well. There's like a core line of development here which is like driving a series of devnets to Mainnets. The closer we get to Mainnet, the more that should look like the actual mainnet configuration. There will be parallel streams of testing more aggressive Bpo schedules, and we should also have those. But I'm trying to dial in on what we actually want. Mainnet to look like.

yeah. okay, I mean, I guess I have a question. Then when we say, Bpo, one and Bpo, 2. Here like, what? What does that mean? Like, what specific numbers.

Barnabas Busa: We are thinking a mild increase in Bpo one. So something like 8 and 12 in Bp, one or 9 and 12, I'm not sure what the correct ratio would be.

Parithosh Jayanthi: I think part of the issue is that we haven't had network stable enough for long enough to actually do any analysis. Most of the networks we've had are like 5,000 nodes. We would at least want to do the non finality network as well as the really large network. So about a thousand nodes, and then collect the data from that before we can even decide what Bpo, one and Bpo 2 value should be. Otherwise, we're just kind of guessing.

Alex Stokes: Yeah, okay, that makes sense. But then what we can, I think, agree to today is just the shape of having only 2 Bpo scheduled with Osaka. And of course, you know, that's all. Pending further development that we do. Okay? Great. And Oscar has a comment in the chat that yeah, he likes that. Yeah, that seems seems to be what most people prefer at the moment. Okay, so I believe, let me see if there are any last minute items here on the post. Nope, okay, so I think that's what we have for for soccer. Anything else before we move to Glamsterdam.

Okay, so happy, Osaka in, and then we'll now shift to Glamsterdam and think about the future. And for Glamsterdam. Yeah. So some of this, I think we're doing this process for the 1st time, so I think we will kind of figure out. Live the right way to do it. One thing I did want to call out today is that there have been a number of these headliner proposals and going off of the schedule that Tim had posted some some time ago. We're kind of nearing this end of the headliner proposal section. We would then shift to deciding on a headliner. and you know, keyword, there is a single headliner per layer, right? So there's a number of headliners. The idea here is that the headliner is, you know, there's 1 of them. And it's like this core sort of feature

that carries the fork. And so what that means, then, is that we would actually pick one seal headliner on this call you know as well as one El headliner on the acde call. and my sense is that with the socca and everything, it's a bit early to go ahead and make that Helena call today. But I did want to go ahead and just say we should focus on picking one. I will note, because we're here mark from Lighthouse had a comment on the agenda that they would like to propose 7, 7, 3, 2 as that headliner. I will just mention that for now. Just so, it's on the record. But what I wanted to do instead today was just go through the set of headliners and try to narrow down the set to things that we know we don't want, or rather things that we do want by pointing out the things we know we don't want. So this is kind of like this Dfi status that we have for IP selection, but for the headliners.

So if that sounds good to everyone. Then, actually, let me read this chat here from Onsgar. Okay. So they're gonna wait until devoted 3, and then perhaps we should do the same thing on the cl. so yeah, I mean, I'm open to opinions on this, what people think the right processes. But it's possible we kind of want to pick them together. so it might wait, might make sense to wait. Wait even then. Okay, also, just to add context to what I just said about Lighthouse Post. It sounds like there's still some discriminant there. But there was this one opinion from Jay King. But I'll just copy here and point being is, I think this is highlighted is a bit early to pick the headliner. But yeah, okay, on score.

Ansgar Dietrichs: Yeah, I think I mean, I agree that I'd probably try to align roughly, kind of between Acdc and Acde, and basically like, wait a little bit longer for the full discussion, but I do think maybe if we already have it on the agenda for today, anyway, we could at least briefly have a look of like which of the headliners are even kind of Cl side. So how many do we have you, for example, also on the agenda made the point of that. You don't think that we could combine more than one headliner, at least on the Cl side. So basically like at least briefly kind of like. or you talk about the kind of parameters of what? What the goal here is in terms of headliners.

Alex Stokes: Yeah, yeah, exactly. So yeah, let's get into it. Then. So let's see, I'm actually gonna go off of this website forecast. I'm not sure if people have seen this. But they should all be here. And it's a nice little ui. So okay, let's just focus on see all things today. And that means, so yeah, we have 7, 7, 3, 2 Epps very much than 7, 7, 8, 2, which is reducing the slot times to 6 seconds. They're 7, 8 0 5, which is fossil. Delayed. Execution, I would say, is mostly an El concern. So we'll leave that out unless someone wants to touch on it. One thing there is like it does kind of touch on many of the same design concerns as Epps

period is here which this one would touch on some Cl things because there's a number of Sfz changes. Sorry. I just clicked the wrong button block level access list. We can put to the side evm, 64. And this available attestation one. So okay, out of the set here, then, yeah, we have Eps 6 second slots. fossil period and available attestation. So from there, I guess, yeah, maybe following them from Oscar's point, like, you know. how do we want to go about this like one idea I had for today was essentially to say, like, we can dfi particular headliners that we know we don't want, and that will then narrow down the decision set for people to then go and make their selections for future calls.

So hmm! I guess I'm open to anyone who wants to speak up and propose a particular efi for a headliner. and what I mean there, it's kind of a shorthand, but essentially like things we think we don't want as the single headliner and maybe to make this a little easier. Well, yeah, it's a little tricky without just editorializing some eips. So anyone have any thoughts. I guess I could start it this way. Do do people feel that? Okay, this is tricky.

Because I don't wanna really bias the discussion here? Hmm.

Marius van der Wijden: I. So I would just go through all of the all of the different proposals and see if there's someone, some client team who's who's who says that this is something that they categorically, categorically do not want.

Alex Stokes: Okay? Well, then, we can just start here with your comment, Marius, where it says you don't think we should do this available attestation thing. So yeah, does anyone feel like we should have that as a headliner. So yeah, maybe just a process note with. And see, are all these proposal? Eip Cfi. So I believe none of them are Cfid for Amsterdam. Right? We're still at the point, I think, of selecting someone. Correct me if I'm wrong on that. But I think essentially we would have these selected and then, I guess, like, for example, when once we select the headliner that would be Cfi, and then there'll be a second stage where we Cfi other things and proceed that way.

So okay, going back to this available attestation eip, it seems like that should not be a outliner. So I think we have agreement there. And please someone, speak up. If you feel differently. Okay. I guess then I'll just kind of go in reverse order here on this list. So then, period like, do we feel like periods should be? Oh, so yes.

Saulius Grigaitis: Yeah.

Alex Stokes: Did you have a comment? Yeah.

Saulius Grigaitis: Yes, so so my comment would be. maybe we, instead of trying to pick a particular eip, maybe we should try to pick a particular theme that is most important for the next upgrade, for example, the the Peerdas was quite good thing, because the the actual theme was that we want to scale blobs. So so my proposal would be, maybe we should 1st try to figure out what is the most important thing that we want to improve instead of trying to to pick a particular eip. Because when when we are focusing on particular eip, we kind of slightly to the to decide the the main thing what? Exactly we want to improve in theory. So so that would be my proposal how to proceed with with this.

Alex Stokes: - yeah, no, I think that's a good way to go about it. And we had discussed this some maybe like 3 or 4, maybe even 5. When once we had 1st opened the like landstream discussion on Acdc. We had spent some time talking about this, and at the time at least we had said, scalability was this theme? Then the question is like, okay, like, does epbs scale? And you can make an argument there. There is even an argument that fossil in some sense falls under the scaling theme. But yeah. So I would say, generally, there's agreement on scaling being this theme. And maybe we need to like, decide exactly what scaling means here. But then, ultimately, yeah, you know, I think.

assuming we all kind of understand a little bit what we mean when we say that then I would say that would rule out things like available attestation. Things like period. Also, I think is an open question. And then from there there's just this ongoing conversation of epbs 6 seconds, slash late execution, and how we want all that to fit together. So with that being said, do we feel like that's a reasonable assessment of the headliners. So far. Oscar. I don't know. If you had a comment to that or something else.

Ansgar Dietrichs: Yeah, specifically to that point. I just wanted to say that in principle, I think having some sort of general direction of the folk makes a lot of sense to me, and I agree with. But you know you you said about making it about scaling the l. 1. But I just wanted to say that to me that is less clear on the Cl. Side than on the El side. So I think, on the El side, once we have that conversation, that that's something that I will push for very actively, I think, on the El side, like all of the main features that I find attractive are around scaling block level access lists. And then on the non-headliner side, basically like pretty severe repricings. And so that will basically give us a lot of headroom for scaling

to me, then that makes it much more optional on the Cl. Side to also follow the same theme, because, if we, for example, prioritize delayed execution, which we very well might do. And then we just get like a very big one time scaling bump out of Glam Saddam, and then basically plateau afterwards, whereas, given that we already get this bump out of the El. It would also be totally fine to say on the Cl. We focus for one more fork on something else like say, for example, shorter, slot times, I think, is the main contender that I've heard for people that don't like epbs in Glamsterdam. And then we would basically only do these Cl side scaling improvements in Hstar.

So so I was just. I just want to say that, like the the general theme of scaling, I think, is more binding on the El side than on the Cl. Side.

Alex Stokes: Fair. And then, you know, like, you could imagine when you scale in a more or less sense, right like you could start to make the argument that shorter slot times does scale things. Or. well, yeah, it's actually hard to make the argument. But yeah, okay, but yeah, fair point. Yeah. Also from here. There's like a bunch of discussion in the chat now. And I think, let me read Phil's message here makes sense that within. Right? Yeah, so yeah, Bill, to your point, this is kind of what I wanted to do today. Just make the claim that. Well, okay, what I had said is that we would make the headliner selection on the next Acdc. Given the pacing of Acde. I think I'm gonna at least I would propose to push that back to be more aligned with acde.

So what that means for today is that we're still kind of in. We're not quite at the point yet where we can actually decide headliners. Which I also think is good, because, again, just referencing the chat, I think there's still pretty active discussion around all these different things fit together. So on that point, I'm not sure we're going to make much progress on this further today. yeah, Barnabas, I'll echo what you have here in the chat making a statement about preferences would be really good. Because, yeah. Otherwise we'll just kind of. we could easily go in circles synchronously on, you know, some given Acdc. So, having some thoughts written down, is really useful. And again, timeline wise, then I would say, we probably have more than 2 weeks.

I'll circle back with Tim to see exactly what he's thinking on acde side. but I would like to kind of have them happen concurrently. So yeah, I think that's probably on this point for today. And takeaway being keep thinking about that liners that you'd want. It does sound like, there's preference for some combination of epbs or 6 second slots or fossil as headliners today. But yeah, again, the conversation will keep evolving. Okay? So then, in that case. I think that's all we had on the agenda. Are there any other comments or points someone would like to bring up today?

Okay? If not, then we'll go ahead and wrap up. Thanks, everyone. Bye. Everyone. Well, okay, there's still some discussion in the chat. I don't know if we want to keep this going somewhere. or if people would like to speak up. but otherwise we'll go ahead and wrap up the call.

Potuz: Can we make a deadline? Perhaps? I mean, we had a deadline for like 2 weeks from now. And it seems that we're not gonna get there. Not even close.

Alex Stokes: Yeah. So I think it's kind of hard to say. Onsgar, do you want to speak to the comment you had? I'd have to go find it. But you had a comment in the chat.

Ansgar Dietrichs: Oh, you mean on the on the time? Timeline? Yeah. So I think basically on on the Acde side. The decision was to basically 1st wait until the basically, the immediate attention on Fusaka is kind of lower meaning that, like Devnet 3 is out, and there's no like emergencies around Devnet 3 non-finalization or something anymore, to take up most of the attention of the call. And so once we have a call to start focusing on headliner discussion that we would then have one call for discussion, and then the call after for for decision, basically. So it's a 2 week, 2 like a 2 week span for making that decision so effectively. That would mean that probably next week's acde at least, would still be Fusaka related. And then

either the 2 weeks and then 4 weeks after would be the ones for the decision. So 5 weeks from now, or if there's any hiccups or something with definite 3, then that would be delayed by another 2 weeks. Basically.

Alex Stokes: Yeah. So to play that back to put us this question around deadline, I think I I like that like, basically, let's focus on Devnet. 3, for now once. Devnet 3 is healthy. Then we would then engage the headliner discussion. And yeah, having a call for a discussion, and then another call after that to make the decision seems pretty reasonable. Does that work for everyone here? Yeah, let's go.

Ansgar Dietrichs: Yeah, not on the timeline. Just one last general comment. I do think it would be healthy if we all could also like then already like over the next 2 weeks. Think about how we could ideally service some some kind of opinions from kind of ethereum stakeholders that don't usually participate in Acd, so that we don't end up in a situation where we make the headliner choice, and then everyone else is like, Oh, you didn't listen to us, or something, I think, in this like fork. The risk of this is lower. But still, yeah. just want to mention.

Alex Stokes: Yeah, which is just like thinking about it. It seems a little tight, because if we have, say one call to do discussion, and then another call to do decision. That kind of implies you'd want all these different stakeholders on the one discussion call which we can do. At least we could try. But yeah, it's might be a little tricky to coordinate everything. The alternative is, we just take the time between now and then to just try and get these different voices on Acd. or, yeah, I guess other forums as well would be nice. Okay, I think we go ahead and wrap it up unless anyone has anything else.

Barnabas Busa: Could you not schedule that stakeholder meeting for that next Ecd.

Alex Stokes: You mean like next week.

Barnabas Busa: Yeah.

Alex Stokes: I think, sounds good. tricky, because there's probably many different types of people we want to get involved, and it would only be like a week to get them there. There's also, like, I think, a different set of people across Acdc and Acd. So in general, I think we should try to do this, but I think doing it by next Thursday will be tricky.

Barnabas Busa: I mean getting everyone there like PE- people that care about. The next update will show up, and people that don't will not. That's my take.

Alex Stokes: Yeah, but it's more fine grained than the next update. Right? Because it's like, okay, let's say, we want to talk about epbs. There's, you know many people here. There are other people who are in like the Meb ecosystem. There are other people been thinking about shorter slots, and like the ecosystem in different places. So that's just like all on the Cl side. And then I imagine there's slightly different concerns on the El side. Yeah, Onsgar asked. Like, what does schedule stakeholder meetings mean? And like really what we mean here. So I think Botus gives a really nice example of what I was talking about free pps where it's like, you know, this feature would touch the concerns of all these different

ecosystem players. And again, for each IP, you can imagine, like slightly different sets, or in some cases very different sets. So yeah, it just kind of tricky to pull off. And then then from there, you know, it's like, do we need them all in Acd, you know, see? Or C, or d sorry cre, maybe not. Because it might be more convenient to get like Async Inputs say, on 8th magicians or different places like that. I was laughing about Francesca's comment. Here. okay, let's go and wrap up. Thank you all. And yeah, we'll continue the conversation both Async and on the next calls. Thank you all.

Potuz: Bye-bye.

Lion Dapplion: Thank you.

Kolby ML: Thank you for the call.

Ansgar Dietrichs: We have one.

Marius van der Wijden: Thanks, but.

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