stokes:Okay, everyone.
Transcript
stokes:Welcome to Acdc, number 160. I'll drop the agenda here in the chat.
stokes:It's Pm, issue 1598. And yeah, I guess really quickly, thanks again to Onsbar for falling in last time
stokes:I was away. And yeah, still getting caught up on some things while I was out.
stokes:But yeah, let's go ahead and get into it. So
stokes: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.
Parithosh Jayanthi: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.
Parithosh Jayanthi:Okay, I guess that means all the Cls will have it in the in in either their current release or the next release right.
stokes:Yeah, do we want to set some kind of date as a deadline?
stokes: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.
stokes:Yeah.
stokes:I guess more like we could say, Okay, this will be ready by the end of the month, and then
stokes:we can then go and coordinate with everyone else to actually update.
stokes:Okay, I guess this is also something we can just keep bringing up on Acd until it's live.
stokes:Okay, yeah, there's a bunch of comments in the chat here around release schedules.
stokes:So it looks like most people have it pretty soon. Here, cool. Thank you.
stokes:Okay. So now let's get into Fusaka. So
stokes:1st off, I wanted to start with the status update on Pisaka Devnet 2
stokes: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:Yes, loadstar had some p. 2 p. Bug, that they might want to give an update on.
MatthewKeil:So we identified some issues appearing with Nimbus. They did a good.
MatthewKeil:Oh, can you hear me? Okay.
stokes:Yeah, you're good, I think, somehow someone stopped the recording. But you're good.
MatthewKeil: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
MatthewKeil: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.
MatthewKeil:So there's a few things. But Agnes has done a good job of responding to everything.
stokes:Okay, cool. So yeah, I mean, I guess we'll just keep debugging all of that.
stokes: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
stokes:which I'm not sure. Why, that's a note here, but it is
stokes:otherwise, yeah, proposals look pretty good. Participation is only around like 87%. Let's say
stokes:hopefully, that could get a bit higher.
Barnabas:To.
stokes:Bye.
Barnabas: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.
Barnabas:So also, I think Glostar have some memory issues and grinding as well only on this product. So
Barnabas:this issue seems to be only be presented during the super nodes.
stokes:Alright. That's helpful. Context.
stokes: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.
stokes: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: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.
stokes:Okay.
stokes: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.
stokes:So
stokes:yeah. Again. I was trying to catch up from the last call. It sounds like the core pierdos. Things are fairly stable.
stokes:Dare I even say a spec freeze
stokes:from there, though a few other things have come up on Devnet 3 actually let me grab.
stokes:Let's see, I'm trying to grab the devnet through specs.
stokes:Just so people have them handy.
stokes:I'll put them there. Just yeah. Thank you. Just in case people want to refer to them here. So
stokes: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.
stokes:Or, yeah, respond, okay, yeah, I don't know.
stokes:Yeah, I did not. But.
Ben Adams:I I just wanted to confirm they were in devnet 3, because we discussed in an old
Ben Adams:all testing. But yeah, it didn't seem like it was a hard confirm, that was all.
stokes:Okay? And to be clear, I think it is a hard confirm.
stokes:Maybe someone else can help confirm my heart. Confirm.
stokes:Yeah, there's a comment here that I linked from Barnabas that essentially says this cool.
stokes:Okay. So then we can get back to some Cl things.
stokes:So I guess the 1st one to kick us off here on this list would be a proposal to change get blobs so
stokes: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
stokes:role here has a proposal to basically revert back the v. 2 semantics and then move this partial
stokes:idea. And to A. V. 3
stokes: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.
Raúl Kripalani: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
Raúl Kripalani: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.
Raúl Kripalani:But we don't wanna rehash this whole topic, then, so that's why this this proposal has been made.
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.
stokes: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.
Raúl Kripalani: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.
stokes:Right?
stokes: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:Yeah. So for for Nimbus the all or nothing was was pretty good, and
Dustin: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.
Dustin:That's a full and tested and etc. So
Dustin: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
Dustin:so. And at this late date, and and for saka.
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.
stokes:Yeah, launch to then do something better before the Amsterdam.
Raúl Kripalani:And just to just to be.
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
Raúl Kripalani: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.
Raúl Kripalani:and, like the the whole point, is to alleviate, to to avoid any extra coordination at that point in time.
stokes:Yeah, I mean, are people. Okay? Then, reverting the V 2 changes.
stokes:Cause, I think, if so, then we just do that, then, yeah, we do what this Pr is proposing, and one thing is like.
stokes:well, we'd still ideally want to get v. 3 into Fusaka
stokes:but it could be somewhat of an optional thing.
Dustin:Barnabas posted on the issue for this call. That there would be no Fusaka devnet.
Dustin:for if so, I would say, that's, let's say, an extremely aggressive schedule for introducing a a core
Dustin:engine. Api change.
stokes:Yeah, I would.
Barnabas:It's an optional change, right?
stokes:Yeah, well.
stokes: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.
stokes:so ideally it's done.
stokes:But it wouldn't be anything blocking like core R. And D
stokes:as we go to may not. So it's something that could be done, you know, over, say, the next couple of months.
stokes: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
stokes:and then restoring the other. You know the original logic is v. 2, so it doesn't seem
stokes:like that much.
stokes:I don't know if there was a commentary about a Boolean flag, and v. 2.
stokes: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.
stokes:Okay, that one's just that. Okay.
Raúl Kripalani:Yeah.
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.
Raúl Kripalani: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
Raúl Kripalani: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.
stokes:Yeah.
stokes: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.
Raúl Kripalani:Yeah, you're worried about.
Raúl Kripalani:And that was why that solution was deemed. That's why the optionality was included.
stokes:Okay?
stokes:Oh.
stokes: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.
stokes: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
stokes:even before Glamsterdam.
stokes:So
stokes: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.
stokes:And then from there it's more a question of well, I think the limitation is bigger on the Yale side.
Barnabas:Well, we not gonna be able to test it unless
Barnabas:we do an actual partial response right?
stokes:Yeah. But I mean, this is something we can test. Whenever
stokes: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
Marius van der Wijden:is very easy to implement
Marius van der Wijden:and kind of the like. We kind of spec the engine. IP Api this way, so that we allow for these kind of
Marius van der Wijden:soft forks and and changes to the engine in between forks.
Marius van der Wijden:So I don't.
Marius van der Wijden:Yeah, I think this like, there's not much that we need to test there. And basically the testing
Marius van der Wijden:can happen like El only the only thing that we
Marius van der Wijden: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.
Marius van der Wijden:hey, I don't know. This kind of sets us up to do cell level messaging before before Glamsterdam.
Marius van der Wijden:In the software, which I think is very easy very good.
stokes:Yeah.
stokes: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.
stokes:So
stokes:in that case I think I would lean towards go ahead, going ahead and making this change. Anyone feel
stokes:we really should not do this.
Barnabas: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
Barnabas:basically just go ship it v. 2,
Barnabas:and be able to test that, and then we will scope this for.
Raúl Kripalani:Yeah.
Raúl Kripalani:So the
Raúl Kripalani: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.
Raúl Kripalani: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.
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
stokes:to do this.
stokes:but then, at that point it's no longer sort of this pure Vpo idea, and it becomes more just another hard fork.
stokes:But that would give people more time.
stokes:Flc, us, can we just roll back to partial responses. So I believe that's what we have right now
stokes:with V, 2.
Raúl Kripalani:No, so partial, partial. So basically partial responses in v. 2, right, like original original V, 2,
Raúl Kripalani:were not supported. It was all or nothing.
Raúl Kripalani:Then what's currently in master is very relaxed, and it basically
Raúl Kripalani:introduce at the May may return partial responses. Maybe not. Maybe it's on or nothing. Nobody knows.
Raúl Kripalani: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.
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.
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.
stokes:And yeah, like, I think we should stretch to ship it in Frisaka. But
stokes:again, it can be a lower priority, I would say.
stokes: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.
stokes:Yeah, Barnabas. So
stokes: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.
stokes: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.
stokes:Don't know.
Marius van der Wijden:The testing for this is literally like 2 lines.
Marius van der Wijden:I I don't. I don't understand why.
Marius van der Wijden:where people are like, basically we like we have the testing for this already. We're we're testing it with
Marius van der Wijden:we can test it with eels and and hive like the
Marius van der Wijden:there's nothing to be tested there. It's basically, does this method return partial responses or not?
Marius van der Wijden:And then we have the same test corpus that we have for v. 2 as well.
stokes:Yeah, I don't think the testing load is that heavy and
stokes:also dustin to your point, I think, Perry responded. But you know the idea is essentially of Devnet 3. Be the like frozen specs.
stokes: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
stokes:it's not that there's only devnet 3 full stop.
stokes:Okay.
stokes: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.
stokes:So let's go ahead and do that.
stokes:Okay.
stokes:let me find the agenda. Okay, another spec issue, or at least open points with Devnet 3
stokes:we have. Let me just grab this draft Pr here.
stokes: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.
stokes:Get this moving.
stokes: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
stokes:right now. The proposer gives the sign blinded beacon block to say the relay, the relay returns. Then the unblinded
stokes:data. Here the execution payload and the blobs.
stokes: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
stokes:there's a number of things to do here or like things that could be done.
stokes: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
stokes:just changing this endpoint so that it returns nothing at all. And just having this responsibility beyond the relay
stokes: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.
stokes: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
stokes:does anyone have any thoughts on this or questions
stokes:to follow up to the idea?
stokes:Okay, thumbs up from Terrence, and I'll assume that's a thumbs up on dropping their the return.
stokes:Okay, okay, cool scene.
stokes:A lot of thumbs up.
stokes:So let's do that.
stokes:Cool. That was easy.
stokes:I guess. One question. Since we're here like there is a design space, or you can imagine relays do expose the bobs
stokes:almost as like a archival service or something like this.
stokes:Does anyone feel like that's interesting or valuable?
stokes: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.
stokes:So I'm just wondering if anyone has any thoughts either way on this right now.
stokes:when can we test it? I think we can get this implemented pretty quickly. It's a pretty straightforward change.
stokes:although I guess cl clients would need to also update.
terence:This we would require the builder and the relayer changes on the def net right? And I think.
stokes:It's really, there's 30 relay. Yeah.
terence:Okay.
terence:And I mean, we can test this on kurtosis as well. I think.
Barnabas: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.
Barnabas:We are working on it, and hopefully, we'll have something next week.
stokes:Very cool.
stokes: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.
stokes:maybe like, yeah, that would go the 21.st Okay.
stokes: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.
stokes:I think we've mostly handled all the spec issues in the devnet to spec. So then, it's just a question of implementation.
stokes:But yeah, any anything to surface here before we move forward.
stokes:Okay, cool.
stokes:Then I did want to briefly touch from there. Yeah, the plan on actually getting this to Mainnet. So
stokes:I'll call out this blog post from Sigma Prime that I thought was really good. So Jimmy wrote this blog post here
stokes:with their view on essentially getting peer dos to Mainnet this year.
stokes: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.
stokes:That implies, then test nuts something like Heleshke in September something like Sepholia in August.
stokes:which doesn't give us much time to get to that point.
stokes: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.
stokes:We'd have Devnet 3 stable or not. Stables. Wrong word. But we'd have devnet 3, you know, defined, let's say.
stokes:hopefully, there aren't too many things in terms of implementation difficulties from 2 to 3,
stokes:and we could then hope that Devnet 3 is like this happy path, stable paradise implementation.
stokes:From there we want to turn to do.
stokes: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
stokes:I think the main point for today is just to get this sort of rough schedule in everyone's minds.
stokes:Yeah.
stokes: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.
stokes:Okay, Justin says he likes to schedule. Very good.
stokes: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
stokes:reach for Perry brings up. We need at least a non finality network. Right? Yeah, exactly.
stokes:So, yeah, yeah, non finality. Different failure. Scenarios on networks. Syncing is another big
stokes:feature set to to verify.
stokes:But then from there we can decide these different Bpo parameters.
stokes: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.
stokes: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
stokes:pretty broad support for having
stokes:a more conservative rollout with Fusaka, where basically, we just schedule like maybe one substantial increase at launch.
stokes:Then that would imply we have a Bpo update early next year to get us to like a higher number.
stokes:Do people generally feel good about this?
stokes:The alternative would be honestly a more aggressive option where we just try to have like more. Pbo scheduled with Osaka.
stokes:Yeah. Okay, reading the chat here, people are talking about syncing. So
stokes: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
stokes: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.
Ansgar Dietrichs: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.
Ansgar Dietrichs: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
Ansgar Dietrichs:bundled Bpos, together with the Fusaka rollout. If I remember from 2 weeks ago.
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.
stokes: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.
stokes:there'll be almost
stokes:well. There's like a core line of development here which is like driving a series of devnets to Mainnets.
stokes: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.
stokes:yeah.
stokes: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?
stokes:Like, what specific numbers.
Barnabas:We are thinking a mild increase in Bpo one.
Barnabas:So something like 8 and 12 in Bp, one or 9 and 12, I'm not sure what the
Barnabas: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.
stokes:Yeah, okay, that makes sense.
stokes:But then what we can, I think, agree to today is just the shape of having only 2 Bpo scheduled with Osaka.
stokes:And of course, you know, that's all. Pending further development that we do.
stokes:Okay?
stokes:Great. And Oscar has a comment in the chat that yeah, he likes that.
stokes:Yeah, that seems seems to be what most people prefer at the moment.
stokes: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.
stokes:Anything else before we move to Glamsterdam.
stokes:Okay, so happy, Osaka in, and then we'll now shift to Glamsterdam and think about the future.
stokes:And for Glamsterdam.
stokes:Yeah. So
stokes: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.
stokes:One thing I did want to call out today is that there have been a number of these headliner proposals
stokes: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.
stokes: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
stokes:that carries the fork.
stokes: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.
stokes:and my sense is that with the socca and everything, it's a bit early to go ahead and make that Helena call today.
stokes:But I did want to go ahead and just say we should focus on picking one.
stokes: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.
stokes:I will just mention that for now. Just so, it's on the record.
stokes: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.
stokes:So if that sounds good to everyone.
stokes:Then, actually, let me read this chat here from Onsgar.
stokes:Okay. So they're gonna wait until devoted 3,
stokes:and then perhaps we should do the same thing on the cl.
stokes:so yeah, I mean, I'm open to opinions on this, what people think the right processes. But
stokes:it's possible we kind of want to pick them together.
stokes:so it might wait, might make sense to wait. Wait even then.
stokes: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.
stokes:But I'll just copy here
stokes: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.
Ansgar Dietrichs:or you talk about the kind of parameters of what? What the goal here is in terms of headliners.
stokes:Yeah, yeah, exactly. So yeah, let's get into it. Then. So
stokes: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
stokes:it's a nice little ui.
stokes:So okay, let's just focus on see all things today. And that means, so yeah, we have 7, 7, 3, 2 Epps
stokes:very much than 7, 7, 8, 2, which is reducing the slot times to 6 seconds.
stokes:They're 7, 8 0 5, which is fossil.
stokes: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
stokes:period is here which this one would touch on some Cl things because there's a number of Sfz changes.
stokes: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
stokes:okay, out of the set here, then, yeah, we have Eps 6 second slots.
stokes:fossil period and available attestation.
stokes:So from there, I guess, yeah, maybe following them from Oscar's point, like, you know.
stokes:how do we want to go about this like
stokes: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
stokes:the decision set for people to then go and make their selections for future calls.
stokes:So hmm!
stokes:I guess I'm open to anyone who wants to speak up and
stokes:propose a particular efi for a headliner.
stokes: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
stokes:and maybe to make this a little easier.
stokes:Well, yeah, it's a little tricky without just editorializing some eips.
stokes:So anyone have any thoughts.
stokes:I guess I could start it this way. Do
stokes:do people feel that? Okay, this is tricky.
stokes: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
Marius van der Wijden:who's who says that this is something that they categorically, categorically do not want.
stokes:Okay?
stokes: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.
stokes:So yeah, does anyone feel like we should have that as a headliner.
stokes: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
stokes: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.
stokes:So okay, going back to this available attestation eip, it seems like that should not be a outliner.
stokes:So I think we have agreement there.
stokes:And please someone, speak up. If you feel differently.
stokes:Okay.
stokes: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:Yeah.
stokes:Did you have a comment? Yeah.
saulius:Yes, so so my comment would be.
saulius: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
saulius: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
saulius: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.
stokes:-
stokes:yeah, no, I think that's a good way to go about it. And we had discussed this some maybe like
stokes: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?
stokes:Then the question is like, okay, like, does epbs scale? And you can make an argument there.
stokes: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.
stokes:assuming we all kind of understand a little bit what we mean when we say that
stokes:then I would say that would rule out things like available attestation. Things like period.
stokes: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.
stokes:So with that being said, do we feel like that's a reasonable assessment of the headliners. So far.
stokes: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.
Ansgar Dietrichs: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.
Ansgar Dietrichs: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
Ansgar Dietrichs: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
Ansgar Dietrichs:epbs in Glamsterdam. And then we would basically only do these Cl side scaling improvements in Hstar.
Ansgar Dietrichs: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.
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.
stokes:well, yeah, it's actually hard to make the argument. But yeah, okay, but yeah, fair point.
stokes:Yeah. Also from here. There's like a bunch of discussion in the chat now.
stokes:And I think, let me read Phil's message here makes sense that within.
stokes:Right?
stokes:Yeah, so yeah, Bill, to your point, this is kind of what I wanted to do today. Just make the claim that.
stokes:Well, okay, what I had said is that we would make the headliner selection on the next Acdc.
stokes: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.
stokes:So what that means for today is that we're still kind of in.
stokes: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.
stokes:So on that point, I'm not sure we're going to make much progress on this further today.
stokes: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.
stokes:we could easily go in circles synchronously on, you know, some given Acdc. So, having some thoughts written down, is really useful.
stokes:And again, timeline wise, then I would say, we probably have more than 2 weeks.
stokes:I'll circle back with Tim to see exactly what he's thinking on acde side.
stokes:but I would like to kind of have them happen concurrently.
stokes:So yeah, I think that's probably on this point for today. And takeaway being keep thinking about that liners that you'd want.
stokes:It does sound like, there's preference for some combination of epbs or 6 second slots or fossil
stokes:as headliners today.
stokes:But yeah, again, the conversation will keep evolving.
stokes:Okay?
stokes:So then, in that case.
stokes:I think that's all we had on the agenda. Are there any other comments or points someone would like to bring up today?
stokes:Okay? If not, then we'll go ahead and wrap up.
stokes:Thanks, everyone.
stokes:Bye. Everyone.
stokes:Well, okay, there's still some discussion in the chat. I don't know if we want to keep this going somewhere.
stokes:or if people would like to speak up.
stokes: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.
stokes:Yeah.
stokes: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
Ansgar Dietrichs: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
Ansgar Dietrichs: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
Ansgar Dietrichs:either
Ansgar Dietrichs: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.
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
stokes: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.
stokes:Does that work for everyone here?
stokes: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
Ansgar Dietrichs: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.
Ansgar Dietrichs:just want to mention.
stokes:Yeah, which is
stokes: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.
stokes:That kind of implies you'd want all these different stakeholders on the one discussion call
stokes:which we can do. At least we could try. But yeah, it's might be a little tricky to coordinate everything.
stokes:The alternative is, we just take the time between now and then to just try and get these different voices on Acd.
stokes:or, yeah, I guess other forums as well would be nice.
stokes:Okay, I think we go ahead and wrap it up unless anyone has anything else.
Barnabas:Could you not schedule that stakeholder meeting for that next Ecd.
stokes:You mean like next week.
Barnabas:Yeah.
stokes:I think, sounds good.
stokes: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.
stokes:There's also, like, I think, a different set of people across Acdc and Acd.
stokes:So in general, I think we should try to do this, but I think doing it by next Thursday will be tricky.
Barnabas:I mean getting everyone there like PE- people that care about. The next update will show up, and people that don't will not.
Barnabas:That's my take.
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
stokes: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.
stokes: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
stokes:free pps where it's like, you know, this feature would touch the concerns of all these different
stokes:ecosystem players. And again, for each IP, you can imagine, like slightly different sets, or in some cases very different sets.
stokes:So yeah, it just kind of
stokes: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
stokes:sorry cre, maybe not. Because it might be more convenient to get like Async Inputs say, on 8th magicians or different places like that.
stokes:I was laughing about Francesca's comment. Here.
stokes:okay, let's go and wrap up. Thank you all. And yeah, we'll continue the conversation both Async and on the next calls.
stokes: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.
Chat Logs
00:00:13
potuz:Replying to "lol who’s the emoji ..."
Tim was getting the shivers
00:00:16
Ansgar Dietrichs:gm gm
00:00:20
stokes:https://github.com/ethereum/pm/issues/1598
00:00:55
Ansgar Dietrichs:Replying to "gm gm"
I decided to hand control back to Alex.
For now.
00:00:59
stokes:Replying to "gm gm"
Thank you
00:01:35
potuz:Unfortunately Prysm will have it in the next release
00:01:40
Sean:lh just released 7.1 with 45 million default
00:01:50
Lion dapplion:Hello beautiful people
00:01:56
terence:prysm should have a release by end of the next week
00:01:57
Dustin:Nimbus is putting out a 45M release imminently
00:02:02
Barnabas:Replying to "Hello beautiful peop..."
this guy still uses internet explorer
00:02:30
Phil Ngo:Lodestar is testing next release now with 45M bump
00:02:46
Lion dapplion:Replying to "Hello beautiful peop..."
I use explorers of the internet
00:04:08
Raúl Kripalani:interesting, let me know if you need help debugging that
00:04:38
Barnabas:teku had some OOM issues
00:04:53
Mehdi Aouadi:Teku a release by next week with 45M
00:05:49
Dustin:https://github.com/status-im/nimbus-eth2/releases/tag/v25.7.0 is 45M by default
00:06:09
MatthewKeil:Replying to "Hello beautiful peop..."
Hah.... Dora....
00:06:32
stokes:https://notes.ethereum.org/@ethpandaops/fusaka-devnet-3
00:06:56
nixo:Replying to "https://github.com/s..."
dang, you weren’t kidding by “imminent” ha
00:06:59
stokes:https://github.com/ethereum/pm/issues/1598#issuecomment-3057506599
00:07:33
Barnabas:its in the spec sheet, so its hard confirm lol
00:07:43
Barnabas:we just waiting on more approvals
00:08:13
Ben Adams:Replying to "we just waiting on m..."
you are giving me mixed messages 😅
00:08:34
stokes:Replying to "we just waiting on m..."
Approvals here are just process
00:08:41
stokes:Replying to "we just waiting on m..."
Spec sheet is source of truth
00:09:14
Barnabas:Replying to "we just waiting on m..."
While at it, may we ask some more people to approve the open PRs?
00:09:30
Mikhail Kalinin:how V3 is supposed to be tested without CL using it?
00:10:11
stokes:Replying to "how V3 is supposed t..."
We can still test it
00:10:15
stokes:Replying to "how V3 is supposed t..."
Regardless of hard fork schedule
00:11:40
Roman:can we just add bool flag to v2?
00:11:41
Mikhail Kalinin:Replying to "how V3 is supposed t..."
my only concern would be that V3 testing can delay Fusaka but won’t be used until some time after Fusaka
00:12:42
Raúl Kripalani:Replying to "can we just add bool..."
that was the original proposal, but it was rejected
00:12:52
Marius van der Wijden:Geth is just build like that 💪
00:13:43
Parithosh Jayanthi:Also I think the “no other devnet” mainly means the spec shouldn’t change, wed still have more devnets - e.g a really large over 1k node network
00:13:48
Raúl Kripalani:Replying to "can we just add bool..."
for reference: https://github.com/ethereum/execution-apis/pull/669
00:14:01
Dustin:v3 is a spec change
00:14:01
Roman:Replying to "can we just add bool..."
_sigh_
00:14:30
Dustin:a bool flag is a spec change too
00:15:12
Dustin:exchangecapability is still fundamentally broken because of TOCTOU
00:15:31
Dustin:ELs != endpoint addresses
00:15:46
Mikhail Kalinin:don’t we need to test V3 in a devnet?
00:16:21
Barnabas:how much overhead is this on the CL side?
00:16:21
Marius van der Wijden:Replying to "don’t we need to tes..."
Not really, its a soft fork that we can do later
00:16:33
Barnabas:its clearly a tiny change on the EL side
00:16:40
Raúl Kripalani:we can test it directly (without the CL calling it)
00:16:47
FLCL:it's simpler to update els later. Than maintain another endpoint
00:18:19
Barnabas:if this is independent of fusaka, then why do we care now?
00:18:31
stokes:Replying to "if this is independe..."
We want to ship v3 in fusaka
00:18:40
Raúl Kripalani:yeah, +1 to Marius. the engine API supports ex-fork changes, but we don't have a process to discuss/introduce those that's not aligned with forks
00:18:58
Raúl Kripalani:that's why we're wanting to align it to Osaka
00:20:49
FLCL:can we just rollback to partial responses
00:21:04
Roman:no
00:21:12
Roman:we have full responses right now
00:21:16
Roman:in v2
00:21:39
Roman:as of devnet 2
00:21:48
Mikhail Kalinin:Making CL using V3 will require testing anyway, I see the point on that we may do it without a hard fork, but it will required coordination efforts anyway
00:22:51
Barnabas:i don’t get why we need this before fusaka, if we can just roll it out in between forks anyway?
Without proper testing how are we planning to roll this out between fulu and glamsterdam?
00:23:17
Dustin:except we can't really "rely" on anything not tested
00:23:20
Dustin:it doesn't exist
00:23:28
Dustin:in what devnet
00:23:39
Dustin:barnabus says nothing after devnet-3
00:24:09
J Sunnyside Labs:We can perhaps separately test it on our devnets
00:24:09
Dustin:last words: "there's nothing to be tested there"
00:24:39
Mikhail Kalinin:But we will have to test the CL side of the logic that is related to V3
00:25:01
Marius van der Wijden:Replying to "But we will have to ..."
Why?
00:25:10
kasey:I the main testing concern is that we need to be certain all CLs are resilient to nil values in responses. It would be bad if there was a bug with nil values in the response in a CL; EL upgrades to start using them; CL breaks.
00:25:11
Marius van der Wijden:Replying to "But we will have to ..."
Its important that all els have it by the fork
00:25:20
stokes:https://github.com/ethereum/builder-specs/pull/123
00:25:25
Barnabas:Could more CL devs please speak up
00:25:33
Marius van der Wijden:Replying to "But we will have to ..."
The cl testing will need to happen by the cell level messaging rollout
00:27:02
Barnabas:sendit
00:27:43
terence:when can we test it?
00:28:44
Barnabas:we plan to roll out mev workflow for devnet 2
00:30:02
stokes:https://blog.sigmaprime.io/shipping-peerdas.html
00:31:08
Mikhail Kalinin:Replying to "But we will have to ..."
I agree on the EL side, but CLs won’t use V3 in Fusaka thus we need to test CLs with support of V3 after Fusaka. Probably we can do a devnet after Fusaka to test this CL change
00:31:45
Justin Traglia:I like the schedule 👍
00:31:58
Parithosh Jayanthi:We need at least a non finality network and a really large network to that, data from that would be useful for deciding BPO1 and BPO2
00:32:25
Barnabas:we still missing so many optimiziations for forward sync on the CL side…
00:32:38
Barnabas:during non finality we were syncing about 0.5slots/s
00:32:44
Barnabas:thats deadly
00:33:12
Manu:We need also “perfect peerdas” devnet
00:33:22
Manu:And be sure every clients are able to sync
00:33:27
Barnabas:Replying to "We need also “perfec..."
yup.
00:34:14
kasey:I don’t understand why we wouldn’t use the BPO for the blob increase (even if it’s very shortly after fusaka).
00:34:25
stokes:Replying to "I don’t understand w..."
We would
00:34:55
Parithosh Jayanthi:Replying to "I don’t understand w..."
Yup, fusaka - no change. BPO1 minor change, BPO2 moderate change. Then we can decide how agressive the other BPOs should be.
00:35:15
Barnabas:Replying to "I don’t understand w..."
bundle BPO1 and BPO2 in fusaka makes sense
00:35:24
kasey:Replying to "I don’t understand w..."
That has been the plan for a while I thought I heard Alex say something different, thanks for clarifying.
00:36:33
Barnabas:Replying to "I don’t understand w..."
finger in the air
00:36:48
Ansgar Dietrichs:I personally like the 2 BPOs bundled with Fusaka option:
Fusaka itself without any thoughput bump, just switch to peerdas
BPO 1 shortly after (1 week): small bump (8/12)
BPO 2 1-2 months after: moderate increase (16/24)
further BPOs after that separately released
00:37:08
potuz:+1 Ansgar
00:37:22
Marius van der Wijden:Do we have complex normal transactions in the sunnyside testnets already? So we have additional load on other parts of the system?
00:38:48
Ansgar Dietrichs:Just update from the ACDE side:
We decided to bump the headliner choice deadline significantly
wait until devnet-3 is live
then 2 ACDEs to decide headliners
00:39:20
Ansgar Dietrichs:Replying to "Just update from the..."
so probably decision still 5 weeks out, maybe 7 (if devnet-3 takes longer)
00:39:21
J Sunnyside Labs:Replying to "Do we have complex n..."
Thanks for pointing this out. We didn’t to put complex normal txs devnets this time. We will soon enable this in the next rounds
00:39:31
ethDreamer (Mark):Note lighthouse team is not fully decided yet as not everyone has had the time to be across the discussion
00:39:53
Lion dapplion:Replying to "Note lighthouse team..."
I currently disagree with the lighthouse glamsterdam post
00:40:19
stokes:https://github.com/ethereum/pm/issues/1598#issuecomment-3055296963
00:41:12
stokes:https://forkcast.org/upgrade/glamsterdam#headliner-proposals
00:41:13
Trent:Can you link?
00:41:44
ethDreamer (Mark):Replying to "Note lighthouse team..."
https://blog.sigmaprime.io/glamsterdam-headliner.html
00:41:45
Ansgar Dietrichs:Replying to "https://forkcast.org..."
for an overview of all of them, scroll up.
or: https://forkcast.org/upgrade/glamsterdam#overview
00:43:26
Marius van der Wijden:I don't think we should do aa
00:43:29
Barnabas:I think client teams should state their preference
00:43:31
Ansgar Dietrichs:we are also not fully certain about single headliner yet, right? some people want to have FOCIL combined with ePBS
00:43:35
thomasthiery:Just one thing I wanted to mention: If we can only chose 1 headliner per fork, there is a risk FOCIL might not be included at all (because ePBS + FOCIL or Shorter slots + FOCIL would be too much)
00:43:46
Justin Traglia:Replying to "I don't think we sho..."
Available Attestation, right?
00:43:51
Ansgar Dietrichs:Replying to "I don't think we sho..."
seems like the most relevant DFI candidate
00:43:58
Marius van der Wijden:Replying to "I don't think we sho..."
Yes
00:43:59
Ansgar Dietrichs:Replying to "I don't think we sho..."
at least as headliner
00:44:03
NC:Are all these proposal eips cfi’ed?
00:44:04
Justin Traglia:Replying to "I don't think we sho..."
I also agree, delete
00:44:42
Tim Beiko:Replying to "we are also not full..."
In all of Ethereum’s history, we’ve never pulled this off. Maybe this time will be different, but we should have a very strong reason why we think so.
00:44:44
Trent:Replying to "we are also not full..."
Is this a serious consideration?
00:44:48
Tim Beiko:Replying to "we are also not full..."
It would be nice to not repeat PectrA/B
00:45:04
Ansgar Dietrichs:Replying to "we are also not full..."
I am personally rather skeptical of it as well, just wanted to flag that that's a conversation that is happening
00:45:09
Tim Beiko:We want to CFI one headliner (per layer, max)
00:45:17
Barnabé Monnot:Replying to "we are also not full..."
And double headliners EL/CL? eg 7886 + 7782
00:45:19
Lion dapplion:My take: do shorter slots + FOCIL, and hold on ePBS for later
00:45:32
Justin Florentine (Besu):Replying to "we are also not full..."
i think it is ambitious, but FOCIL can be looked at as the EL headliner.
00:45:39
Justin Traglia:Replying to "My take: do shorter ..."
I think we should do slot restructuring prior to reducing slot times
00:45:41
Barnabas:Replying to "we are also not full..."
Glamsterdam / Glamsterdbm
00:45:48
Tim Beiko:Replying to "we are also not full..."
I think EL + CL headliners can work if they are fairly decoupled.
00:46:10
Justin Florentine (Besu):ePBS and FOCIL are definitely coupled
00:46:18
Ben Adams:Replying to "My take: do shorter ..."
would mean 2 forks for a user impact
00:46:22
Toni Wahrstaetter:For the slot restructuring (DE, ePBS) we need EL <> CL coordination.
Feels like scaling through restructuring is a priority right now, so do 6s slot or ePBS on the CL makes sense.
00:46:26
Ansgar Dietrichs:proposed theme from my side is L1 scaling
00:46:27
Kolby ML:Shorter slots or Shorter finality like 3SF would have the biggest impact for users of ethereum. A massive UX improvement
00:46:46
nixo:i don’t want to slow things down, but it doesn’t seem like the best approach to suddenly DFI a proposal with little warning when the EIP champion isn’t on the call
00:46:47
Ansgar Dietrichs:Replying to "proposed theme from ..."
main CL side headliner for that would be ePBS / delayed execution
00:47:02
Francesco:Replying to "we are also not full..."
@Justin Florentine (Besu) so much of FOCIL is in the CL
00:47:09
ethDreamer (Mark):Replying to "For the slot restruc..."
ePBS doesn’t need EL modifications though?
00:47:11
Raúl Kripalani:Replying to "My take: do shorter ..."
i think delayed execution makes sense after shorter slots (otherwise we're strictly increasing UX latency)
00:47:12
Justin Florentine (Besu):censorship resistance and mev mitigation
00:47:12
thomasthiery:Wrote a note on ePBS and FOCIL compatibility https://ethereum-magicians.org/t/epbs-focil-compatibility/24777
00:47:24
Dankrad Feist:I think it is hard to separate the theme from concrete proposal
00:47:40
Barnabé Monnot:Choosing a theme is a red herring imo. Even https://blog.sigmaprime.io/glamsterdam-headliner.html recognises that the greedy approach should be 7782, but then argues against doing that
00:47:51
Justin Florentine (Besu):Replying to "we are also not full..."
yes, i admit i have to squint a bit to look at FOCIL as an EL feature, it's almost entirely around block building
00:48:13
Dankrad Feist:Replying to "My take: do shorter ..."
also cutting the slack in the slot first will focus minds on what is important when restructuring witb epbs or DE
00:48:19
potuz:Replying to "we are also not full..."
it's a lot about the CL
00:48:39
Dankrad Feist:Replying to "My take: do shorter ..."
I think we are likely to make suboptimal decisions when we restructure while there is lots of slack in the slot
00:48:53
Francesco:Replying to "My take: do shorter ..."
@Raúl Kripalani Delayed execution by itself doesn’t increase latency, except for light clients
00:49:15
Barnabé Monnot:Replying to "My take: do shorter ..."
@Francesco it does if you payload commit and reveal later
00:49:23
Phil Ngo:It probably makes sense on this call to forewarn people that decisions will be made on the Glamsterdam headliner within the next 2 weeks as sort of a “warning” for the champions to show up and defend their EIPs. Gives everyone the opportunity to prepare (even async on EthMagicians) for a conversation like this.
00:49:40
potuz:Replying to "My take: do shorter ..."
not if the reveal is set at 4 seconds ant he commit at 2
00:50:13
potuz:Replying to "My take: do shorter ..."
and we do slot auctions :)
00:50:14
Barnabé Monnot:Replying to "My take: do shorter ..."
@potuz that’s 2 seconds more! quite a lot imo
00:50:28
ethDreamer (Mark):Replying to "My take: do shorter ..."
focus minds on what is important when restructuring witb epbs or DE
I think we’re pretty focused on this already in the debate with ePBS vs DE
00:50:35
Barnabé Monnot:Replying to "My take: do shorter ..."
Slot auctions improve this but have other issues ofc
00:51:10
Toni Wahrstaetter:Replying to "My take: do shorter ..."
@Barnabé Monnot but commit and reveal later doesn't work under delayed exec (7886). there's no block payload separation.
00:51:16
DA | Flashbots:Replying to "we are also not full..."
ePBS w/ PTC is arguably better for CR than FOCIL. Being able to pick your builder can give CR for both public and private transactions; instead of just public.
00:51:17
Barnabas:Could CL teams please prep a statement like LH did about preferences ?
00:51:24
Barnabas:so we don’t keep going in circles?
00:51:45
Barnabé Monnot:Replying to "My take: do shorter ..."
@Toni Wahrstaetter in the current 7886 version yeah, but it was proposed to have a commitment to the beacon header to avoid timing games even in 7886
00:52:08
Ansgar Dietrichs:Replying to "Could CL teams pleas..."
how should we best gather input from non-client stakeholders? both regular acd participants like pandaops / researchers, and non-acd Ethereum stakeholders?
00:52:17
Lion dapplion:Even internal lighthouse opinion has not converged yet
00:52:22
Anders Elowsson:I’ll post some analysis of blob/gas throughput in DE and ePBS in the context of shorter slot times over the weekend. It may be helpful to the discussion as well.
00:52:25
Parithosh Jayanthi:Replying to "Could CL teams pleas..."
How do we get coherence tho?
00:52:25
Toni Wahrstaetter:Replying to "we are also not full..."
@DA | Flashbots interesting argument!
00:52:28
Parithosh Jayanthi:Replying to "Could CL teams pleas..."
More discussion?
00:52:29
Trent:Replying to "Could CL teams pleas..."
Need to balance dissent in team perspectives tho
00:52:31
Francesco:Replying to "Could CL teams pleas..."
Everyone writes a blog post
00:52:35
ethDreamer (Mark):Replying to "we are also not full..."
ePBS is entirely CL
00:52:44
potuz:Replying to "Could CL teams pleas..."
Already had Flashbots, Lido and preconfirmation teams writing about ePBS
00:52:54
Raúl Kripalani:how are we factoring in stakeholder input and how can we gauge the strength of their preference?
00:52:55
Ansgar Dietrichs:I’d be curious whether anyone would want to do FOCIL as the only CL headliner.
00:53:16
DA | Flashbots:Replying to "Could CL teams pleas..."
Idk if flashbots will put out a whole post on epbs. But at least a short opinion on the upgrades.
00:53:18
Barnabas:we should unmute everyone’s mic
00:53:37
Lion dapplion:Get stokes to play music while we continue in the chat
00:53:38
Trent:Replying to "Could CL teams pleas..."
This would be good! Do it
00:53:49
Orest Tarasiuk (t1):Happy to play sth
00:53:51
Tim Beiko:On the EL, we said the July 31 and Aug 14 calls would be for headliner confirmations
00:53:58
Tim Beiko:Assuming no major issues
00:54:05
DA | Flashbots:Replying to "Could CL teams pleas..."
Fwiw we have no serious concerns about any of the headliners.
00:54:35
Marius van der Wijden:https://youtu.be/0Wi8Fv0AJA4?si=qWKQmIcNvt8WrHf9
00:55:00
Raúl Kripalani:Replying to "https://youtu.be/0Wi..."
oh great, i didn't get rickrolled
00:55:25
stokes:Replying to "how are we factoring..."
We should include it
00:56:02
Raúl Kripalani:there are useful considerations on https://forkcast.org/, but no measurable signal intensity
00:56:09
Barnabas:next acde? Nothing else to discuss anyways lol
00:56:13
Raúl Kripalani:Replying to "how are we factoring..."
(so hard to weigh preferences)
00:56:22
Cayman Nava:For lodestar we're currently thinking about headliners ePBS (on the CL side) and Pureth (on the EL side). Will write up a blogpost with more rationale.
00:56:34
Ansgar Dietrichs:doesn’t have to be formal, you all just try to find some opportunities in the next few weeks to talk to your favorite Ethereum stakeholders about their views
00:56:59
potuz:Prysm seems aligned on ePBS, except perhaps Preston :)
00:57:09
Ansgar Dietrichs:what does “schedule stakeholder meeting” mean, who would we invite?
00:57:36
potuz:Stakers, searchers, users, MEV pipeline players, builders, application developers
00:57:50
DA | Flashbots:Replying to "how are we factoring..."
Can we choose a venue to aggregate opinions? Maybe just a thread on ethmagicians?
00:57:55
Raúl Kripalani:can we do an async (written) call for comments from stakeholders, like we're doing with clients?
00:58:00
potuz:I can think of big unions at least: Stakers union, Lido, RocketPool, Flashbots, Titan, Beaver...
00:58:05
Barnabas:just keep the call going till its all discussed lol
00:58:25
Ansgar Dietrichs:Replying to "Stakers, searchers, ..."
right, but those are not the primary people to talk to about shorter slots
00:58:39
Francesco:Replying to "just keep the call g..."
“Let’s go ahead and wrap up… Unless 👀”
00:58:48
potuz:Replying to "Stakers, searchers, ..."
applications developers and MEV pipeline players are the ones driving it :)
00:58:49
stokes:Replying to "just keep the call g..."
😆
00:58:54
potuz:Replying to "Stakers, searchers, ..."
surely they have something to talk about it
00:59:04
Ansgar Dietrichs:Replying to "I can think of big u..."
I think we have focused too much on the infrastructure side in the past, we should bias to listening more to non-infrastructure people