Ansgar Dietrichs:Awesome. Yeah. Hi, everyone. To the to Acdc today I'm filling in for Alex, who will be back for next Acdc.
Transcript
Ansgar Dietrichs:yeah.
Ansgar Dietrichs:we I am. I also guest hosted last week's acde. I'm a little bit less familiar with, intimately familiar with the Acdc topic. So if I kind of make any mistakes, something feel free to just jump in and correct me on anything.
Ansgar Dietrichs:But yeah, let's let's get started. I'll
Ansgar Dietrichs:put the link to the agenda in zoom chat M.
Ansgar Dietrichs:So 1st up, we wanted to talk about Fusaka for most of today's call, and the 1st topic there is Devnet, 2 Barnabas, I think, wanted to give a status update of where we are at there with the launch.
Barnabas:Yeah, sure. So this morning at 10 Am. Utc, we have launched 2. We scheduled to be hit tomorrow around the same time in epoch 256. And then we're going to do a Bpo
Barnabas:every other day. Basically, we're gonna do every other
Barnabas:epoch. 2, 56 is going to be a Bpo change. I have put in the interrupt channel the exact schedule. We're gonna go up. We're gonna go down and we're gonna go up again
Barnabas:till we hit next blocks of 20. So far the network looks very stable this morning. I have raised some Cl questions regarding Nfd values and Cgc values and
Barnabas:those fixes seem to have came in except for Nimbus, that is still, have a incorrect nft value. But I'm sure nimbus team is already looking into it also. On the nimbus side we seem to have some empty blocks produced by Nimbu.
Barnabas:and they are also looking into that
Barnabas:that's about it, for now.
Ansgar Dietrichs:Sounds good. Any any other topics on Devnet 2 or any action items we need to get to on on that topic specifically.
Barnabas:So hopefully, you're gonna be able to test everything, including checkpoint syncing and verifying the new status messages. And
Barnabas:yeah, I'm looking forward to that.
Ansgar Dietrichs:Sounds good.
Ansgar Dietrichs:Yeah. Then, onto the next topic. General Ps, updates, they are just the one thing I wanted to briefly get to is on acdt on Monday. We briefly had the announcement of a new Sunset Labs report, but people hadn't really had time yet to have a look, so there wasn't really much discussion. So I just wanted to give it some room again today in case there was any follow up anything people would want to briefly talk about
Ansgar Dietrichs:yeah, I'm not sure. I think we have someone from from Sunnyside labs on the call as well. If you want to say a few words on just the headline, Findings.
J Sunnyside Labs:Yeah. Hi, so regarding the network bandwidth limits, network bandwidth. We retested with 8 validators.
J Sunnyside Labs:as Barnabas pointed out from the acd call, and we found
J Sunnyside Labs:much less bandwidth usage by prison, and we will retest
J Sunnyside Labs:all the other ceos with def net 2 spec. Once devnet 2 is stabilizes. So
J Sunnyside Labs:yeah, we will give you guys more updates on this.
J Sunnyside Labs:And also we've contacted at least one person from every Cl teams if they need something. So please let us know. Then we can run like
J Sunnyside Labs:or prepare something for individual teams upon request.
J Sunnyside Labs:Yep, thank you.
Ansgar Dietrichs:Thanks. Were there any comments at Barnabas? Yeah.
Barnabas:Not regarding this, but regarding the net too.
Ansgar Dietrichs:Oh, sorry. Yeah. Then. Yeah. Let's proceed.
Ansgar Dietrichs:Go back to that. Then.
Barnabas:Yeah. So I've quickly enabled watchtower on the 2. So this means that if you push a new commit to your existing branch for like a 2 branch
Barnabas:and we trigger an automatic image build, we will automatically pull the images
Barnabas:every 2 min. We're gonna be checking. If there's a new docker image available.
Barnabas:So in case you push now something to the branch that is untested, or something that's broken that might take your entire
Barnabas:find offline.
ethDreamer (Mark):Just wanna ask if cause Cp doesn't have that branch. But you're saying, if I if we make one, that we can continue to iterate on that. And it will be built automatically. Okay.
Barnabas:Yes.
Ansgar Dietrichs:Sounds good. Then to come briefly back to the Sunnyside labs. point! Was there anyone who maybe also, or had a look or any any follow up questions or comments regarding the report for Monday. Anything more on this topic.
Ansgar Dietrichs:otherwise.
Ansgar Dietrichs:are there any general like? We have a few concrete updates to go through in a second open Prs and discussion of Bpo strategy and and spec freeze. But before that, any general kind of Ps testing updates.
Ansgar Dietrichs:Okay? I mean, I assume, just like everyone was waiting for Devnet to. Okay, then let's go to the specifics. We have a few open Prs. We wanted to talk about. Justin had put them into a comment on the agenda. Let me briefly link that that was 5 open Prs. Although the last one is not specific to Fusaka, so we'll talk about that separately in the section afterwards. So it's only the 1st 4 here that we will want to briefly talk about here.
Ansgar Dietrichs:basically just to make a decision ideally today, on like whether to merge or close them. Yeah, I'll just go through through the 4 of them. So the 1st 1, 4, 3, 9, 3 by Anish from Nimbus, I think. If you're on the call
Ansgar Dietrichs:to briefly talk about this.
Dustin:I don't know if Agnesha's I'm
Dustin:I'm here. I'm on the call. It is Agnesia's Pr.
Ansgar Dietrichs:Since. Yeah, if you have the context on this then that would be great. Yeah.
Dustin:Sure. So I believe this. This is the one where it removes the the pure, pure sampling, and
Dustin:like correct me if I'm wrong. Because that's why I'm gonna that's that's my back. And
Dustin:so the idea is, peer sampling was an earlier iteration of a broad design goal that that now is being fulfilled in a in a different way. I want to kind of avoid getting into too details here. I can talk about if people want but that validator custody?
Dustin:And and so it essentially got replaced a little bit by validator custody in its overall role.
Dustin:And and importantly, not a single team. We haven't been testing it. We haven't been deploying it at the most. Anybody is is really kind of saying about this as well. Maybe in some future time. This might be a useful technique again. But but the idea is like, for now we're practically not using it. Don't have this part of the spec. If somebody wants to be introduced, make make it sort of aligned to spec with what people are doing and what we're actually planning on in the near term.
Dustin:If people want to reintroduce this in a future version of pure dos or full dos, or something else, and we can do that. But.
Ansgar Dietrichs:Thank you. I'm read through the context on this. Does anyone else have comments on?
Ansgar Dietrichs:I mean, it sounds plausible. This is the general agreement to to match this, or is there disagreement? Or.
Ansgar Dietrichs:yeah, I guess maybe the better question by numbers from chat is exactly like more, more concrete. Anyone opposed to merging this in.
Ansgar Dietrichs:Okay, then I think the decision is to merge that
Ansgar Dietrichs:awesome. Then the second pr is
Ansgar Dietrichs:from Manu, I think. And I think I see I saw you on the call. Right. Could you briefly talk about that?
Manu:Please tell me if my connection is bad, actually,
Ansgar Dietrichs:We'll do, for now it's good for now it's good we can.
Manu:Okay, perfect society is right now.
Manu:it is not possible to request a data colon by a root for finalized block. It is only possible to request by Roots Colon for unfinalized block.
Manu:I guess this comes from the copy paste from Blobs, which
Manu:itself was a copy paste from blocks, because some
Manu:some clients does not store finalized and unfinalized blocks
Manu:in the same way in the debit.
Manu:But for the tech columns, I guess it would be very useful to be able to. Yes, to request. Finalize the tech columns by root.
Manu:For the reason I describe a little bit more in the pr description, like, if you
Manu:request a lot of data columns by range. But if for any reason there is few scars missing data columns in the response, then you have to generate a bunch of new by range data columns, requests which is not very convenient.
Manu:And if we can request data columns by root, we can just generate only one request for all missing data columns.
Manu:which is more convenient.
Manu:That's all.
Ansgar Dietrichs:Any comments on this Pr, I think I see lighthouse in favor of merging
Ansgar Dietrichs:any. Basically, again, any anyone who would be opposed to this Pr.
Ansgar Dietrichs:Then again, we can go forward and merge it perfect. Then onto the 3rd one,
Ansgar Dietrichs:4, 4, 0, 6. I think that was from Justin. In in a conversation with with people from lighthouse. If I'm not mistaken.
Ansgar Dietrichs:does. Is anyone from from lighthouse with comment on and with context, on the call that could talk about this one.
ethDreamer (Mark):I don't know that it was from us for the clarifications.
ethDreamer (Mark):It was kind of as a result of multiple
ethDreamer (Mark):like a discussion among multiple cl clients. But I don't see any issues with this.
ethDreamer (Mark):The clarifications are are definitely necessary.
ethDreamer (Mark):I don't think they really change
ethDreamer (Mark):like change. What was what was discussed at
ethDreamer (Mark):the Berliner Berlin torat, but they they make it explicit, and they make it visible. So.
Ansgar Dietrichs:Yeah.
ethDreamer (Mark):4, 4, 0, 6, right.
Ansgar Dietrichs:Yes, that's right.
ethDreamer (Mark):Yeah.
Ansgar Dietrichs:Yeah, sorry again, again, context on these. But but yeah, okay, I mean, that sounds like it's it's not really changed. Just justification.
Ansgar Dietrichs:then, yeah, if sounds like, like, is there is there anyone that that has context on the on this? That? The people? Yeah, Francisco.
Francesco:No. Sorry. This is actually about the the 1st pr. Again. So 1st complete this discussion.
Ansgar Dietrichs:Okay, yeah, we'll get back to the 1st one in a second. But then first, st just to stay with 4, 4, 0, 6 anyone who has contacts on this would be opposed to merging
Ansgar Dietrichs:4, 4, 0 6.
Ansgar Dietrichs:Okay, then sounds like we would also be
Ansgar Dietrichs:good to go with merging the 3rd one, and then we have a 4th one. But before we get to that, then let's briefly revisit the 1st one. Francesco, you had some comments.
Francesco:Yeah. Sorry I should have said you before, but I I thought Jimmy might be here, and but I think I see, is not an yet sent on this court like earlier this morning.
Francesco:basically like he had expressed that he he doesn't necessarily think that we should get rid of the pure sampling. Spec.
Francesco:I think it would be okay to still go ahead and do it. But I think this is a fairly
Francesco:like, I don't think removing this or not removing this is gonna affect anything like, as we kind of said, like, the point of removing is that no one's actually implementing this so I think you'll be okay to make this change whenever. So maybe we can just let this like sit open for a little bit more, and, you know, actually finish the conversation with the middle parties involved. Again. I don't think it's a big deal big deal either way, but.
Dustin:I I personally, I mean, aside from everything else that I find a lot of value. And here I'm not trying to speak on behalf of magnesia or anything. A spec that clearly delineates what is and is not actually real. We have a couple of other corners in the specs here, where, especially in the more experimental ones where they're, they're not actually real. Nobody implemented them ever. And I think those are unfortunate, too. But as this moves into production. I think it's worth being very, very clear
Dustin:about what is real and what is not. And right now this is not real.
Francesco:Yeah, I mean, I I agree. I think if it stays, it should be like
Francesco:somehow made clear that this is not a part of the spec that the the clients are implementing right now, or something like that. I think that
Francesco:the argument for not removing is something along the lines of this is something that you could implement after fully was live without necessarily coordinating with other clients, and and so on and so forth. Whereas I guess if we didn't have it in the spec, that sort of maybe would require
Francesco:yeah. Then re-adding into the spec later.
Francesco:but yeah, I don't know again. I don't have a strong opinion on this. I I am just saying, like Jimmy specifically
Francesco:express an opinion against removing it. But
Francesco:but I think you just like this conversation. I think maybe was in a thread. I don't know this kind of thing, that it was a bit lost somewhere, and at least I personally don't find much urgency in changing this, because it doesn't affect at all what what's happening with the
Francesco:the things that people are actually implementing. So I would consider maybe holding off on this for a few more days. But I I don't know. I'm okay. Even if we decide to merge that. That's fine with me.
Ansgar Dietrichs:Yeah, I mean, given that there was quite a bit of support from merging it, I would be, is there basically anyone anyone else that would be would would be in favor of of waiting one more round of comments for a decision here. Sounds like we wouldn't necessarily need need this for for saka work to to move forward, so
Ansgar Dietrichs:default, I would still go ahead and merge it. But if if there's anyone else
Ansgar Dietrichs:would prefer to to hold off on this one
Ansgar Dietrichs:sounds like, so if if no one is implementing it and in the chat, if if they also, it sounds like Jimmy would not be super opinionated about this. Just had some concerns. So then
Ansgar Dietrichs:I would say, unless someone disagrees. Now, I think we would stick with the decision and just merge it.
Ansgar Dietrichs:Okay, then, that's stick with that. And if you feel strongly about this, then
Ansgar Dietrichs:later point in this call like, speak up or otherwise. That's that's the decision merging the pr, okay, then we have one more Pr in this section, the last one. Let me
Ansgar Dietrichs:have a look that one was, I think, also from
Ansgar Dietrichs:just in in a conversation with Casey, I think, originally, but also maybe several people involved. I'm not sure if either Casey or someone else who has context on this Pr is on the call. I'll put the link in chat.
kasey:Is this about 4? 4? 0, 7.
Ansgar Dietrichs:4, 4, 7. 0, yeah, sorry I should have. I should have mentioned that. Yeah. 4, 4, 7.
kasey:Yeah. So this is just kind of clarifying some of the language around the requirement to disconnect. If the Nfd doesn't match currently says that you must disconnect at the Fork boundary, and what will happen, and and the way things have been worded previously is, if you're not on any of the same topics, and you're not agreeing with fork digest for the purposes of Rpc. Encoding. You'll just
kasey:downscore each other and not have any positive peer score activity, and you'll just disconnect and so like, we can kind of let that happen. And if
kasey:people want to implement this, I think it's I think it's fine, totally, but optional, and it seems like Raoul agrees in the issue, and I think he introduced that word originally.
kasey:So the idea is to just clarify that you must not disconnect before. But you know you may. You may, after.
Ansgar Dietrichs:And Mac.
ethDreamer (Mark):Yeah, I mean, I I don't know if you said that the existing language was that you must disconnect before, because
ethDreamer (Mark):if that was the existing language.
ethDreamer (Mark):I would. Yeah, I would say that this
ethDreamer (Mark):oh, at the fort boundary, but not sooner. Oh, okay, none of mine. So
ethDreamer (Mark):I do like the clarification. Yeah.
ethDreamer (Mark):I just thought I thought it was more needed. I thought, the the original language is wrong. It looks like it's just
ethDreamer (Mark):clarifying and and adding things sorry.
ethDreamer (Mark):But yeah, I do support.
Ansgar Dietrichs:Awesome. And would there be anyone opposed to imagining this? Then?
Ansgar Dietrichs:Okay, then, I think, looks like we will go 4 to 4, 4 to 4 and 4 on merging. So we'll also merge. This 4th pr.
Ansgar Dietrichs:perfect. So that's those are the prs, at least the the ones directly relevant to to Fusaka.
Ansgar Dietrichs:And then next up. Next topic we wanted to talk about is the question of spec freeze for Fusaka. Basically like, are we ready for this? How much close to to it are we? I think, Barnabas, you wanted to say something to to get that conversation started.
Barnabas:Oh, sorry
Barnabas:I thought I was unmuted.
Barnabas:Which conversation.
Ansgar Dietrichs:Oh, just the question of whether we are ready to do for spec freeze, for for
Ansgar Dietrichs:for the Fussaka spec.
Barnabas:I think we should be.
Barnabas:I think we should be ready to freeze this back. Yeah, at at least on the side once. All these 4 Prs are merged in we should be able to have another offer release, possibly
Barnabas:office 3, and then going forward, we should be able to do better receipts. That will be. Doesn't specific races.
Barnabas:does it? Any of these cl, devs feel like there's still some open questions regarding pure desktop especially, or Bpo. Spec.
Barnabas:I think there was one more open Bpo question regarding the Max transaction.
Barnabas:But that's it's more of a question for next week. I think.
Ansgar Dietrichs:And then, just for my understanding, would that mean that because we will still have a devnet? 3? Obviously so, there would not be any expected changes anymore between Devnet 2 and definite. 3 from the Cl. Spec. Side.
Barnabas:Yeah, from the sales back side. Only these 4 Prs, but none of these would be new. As far as I understand, all these clarifications are already included in that. Not too.
Barnabas:And yeah.
Barnabas:these Prs, once they are merged in, we should be basically spec complete for on the sales side.
Barnabas:and then physically, could possibly launch in approximately 2 weeks with the adjusted 7, 9 0. 7, and possibly any other vip that needs repricing
Barnabas:for Devnet 3, and then devnet 3 should be the frozen spec.
Barnabas:and that should be the spec that is touching Mainnet.
Ansgar Dietrichs:Right and.
Barnabas:Except for Bpo's, because at this point we still don't know the Bpo values.
Ansgar Dietrichs:Makes sense. Yeah, just for clarification for people listening. So we will still like this would only be freezing on the Cl. Side and then on the El side. Basically, we will have another next week where we would then freeze the fully. Freeze the El Specs. There's still a few very last things in flight there for for 3
Ansgar Dietrichs:and then basically that the hope would be that that would be the
Ansgar Dietrichs:the specs that, as part of said that would not include the specifics of the Bpo fog values, even though they might at least some initial Bpo fogs will be rolled out together with the client releases for the main Fusaka fog. But that's still separate forks, basically. So those are specifically not what we're talking about here, freezing. But the Fusaka spec itself. Then
Ansgar Dietrichs:would be frozen from on the Cl side.
Ansgar Dietrichs:of course, pending no issues during testing that that actually
Ansgar Dietrichs:requires to to make changes further changes.
Ansgar Dietrichs:Is there anyone that feels like we are not ready for that? Is there anyone that still has concerns that? This this would be premature, or are we generally
Ansgar Dietrichs:feeling good about this?
Ansgar Dietrichs:I mean, it sounds like, maybe no one has serious concerns. And so my understanding is that there's a chance. We would want to launch definite 3 before the next Acdc. Right? So if next Acdc is in exactly 2 weeks, it could be that we're launching Devnet 3 before then. So basically that there will be no further Acdc before that aspect is fully frozen. So so, indeed, that this is the last moment in time, basically awesome. But then with that, I guess.
Ansgar Dietrichs:unless something unexpected happens, then Fusaka Cl side specs are frozen
Ansgar Dietrichs:perfect.
Ansgar Dietrichs:That that was easier than thought,
Ansgar Dietrichs:okay, then we can move on to the next topic, the last one for Fusaka, which specifically is exactly about the part that's not frozen, which is the Bpo strategy. So basically like these kind of
Ansgar Dietrichs:tiny parameter. Only folks that we will have after Fusaka. I think there was a Sigma prime blog post, I think. But, Jimmy, but I think Jimmy's not on the call. If maybe someone from Sigma Prime would want to
Ansgar Dietrichs:M.
Ansgar Dietrichs:Talk a little about kind of the the Sigma pine. Thoughts on this to get us started.
ethDreamer (Mark):The the post was mostly about
ethDreamer (Mark):about like wanting to freeze the specs. So I think we more or less
ethDreamer (Mark):just decided that and the Sigma Prime team was in favor of freezing the specs.
Ansgar Dietrichs:Yeah, sorry about that. I thought I thought reading it. There was also something about basically like
Ansgar Dietrichs:good basing to what's basically shipping I don't know. I thought there was also some.
ethDreamer (Mark):It wasn't suggested, like target for the blobs.
ethDreamer (Mark):that we would ship for up to to maybe 18 blobs at the at the fork boundary, and then maybe have a Bpo for it for 24.
ethDreamer (Mark):But yeah.
Ansgar Dietrichs:Okay, then. Yeah, thanks. So sorry about that. Then then kind of
Ansgar Dietrichs:misplaced that article a little bit. Okay? Then I think Barnabas and Pawri. I'm not sure which of the 2 of you I think you both had some specific thoughts on the kind of the the which Bpos to to potentially bundle with the initial mainnet releases of Fusaka. And
Ansgar Dietrichs:yeah, basically, the general strategy approach here.
Parithosh Jayanthi:Yeah, maybe I can start with some context, typically for the Neb as well as Electra. We had a bunch of analysis on mainnet that was done to try and arrive at a block. Count that we deem
Parithosh Jayanthi:the network can handle
Parithosh Jayanthi:however, with pierdas that changes, we can do all the analysis we want right now. It just won't really mean much for a post peer das world. Which is why our proposal would be to have a very conservative bump immediately. After Fusaka, so that could be Bpo one.
Parithosh Jayanthi:So that would essentially mean we have Fusa. We get roughly, let's say, a week, 2 weeks, whatever worth of pristine data where we can comparedas and post periods.
Parithosh Jayanthi:And then we have Bpo, one that increases blob counts by a relatively small number to give us some scaling short term, and then we can actually do all the analyses that we want on with the main data, and then we can schedule the next 2 Bpo's, which can be a lot more aggressive if required, and in general, I think the plan should be that we can, we should ship
Parithosh Jayanthi:at Max. 3 Bpos, because trying to do analyses beyond that, on how the network might predict might behave in the future is kind of hard. Yeah, we wanted to propose this as a general strategy for Bpos, and see if there was any initial reaction or opinions from clienteles.
Justin Florentine (Besu):When you say a small bump for Bpo. One. Is there a number that we have in mind already?
Parithosh Jayanthi:Yeah, I think we were imagining like 9 12.
Parithosh Jayanthi:But again, it's an open question. I don't think we have a
Parithosh Jayanthi:yeah. The Sigma Prime Post, for example, talks about 18 instead.
Parithosh Jayanthi:I think one of the other side effects of this staggered ish approach is that we can also let demand catch up. Faster.
Parithosh Jayanthi:Yeah, I want.
pawan:Yeah, when you mentioned that like, post Bpo, one like we can have more aggressive targets if everything looks good like, what numbers did you have any numbers in mind for that as well.
Parithosh Jayanthi:I think that's the tricky bit, because until the data is there, I feel like it's hard to make a prediction. The good thing is Sunnyside labs networks, as well as all the hardening stuff we do over the next one might give us a nice upper limit. And then we can choose how close to the upper limit we're going on subsequent. Bpo's. But yeah, I don't wanna give a number right now and then have to backtrack it once the data is there?
Parithosh Jayanthi:I guess the overall question is, then, are we okay with the blob numbers looking different on test nets versus mainnet. Do we wanna just have all the Bpo scheduled on testnets? What's our strategy? Because I would assume we don't want to go through the whole testnet. Bpo mainnet, Bpo. Cycle for the future.
Parithosh Jayanthi:I guess in general, are we okay with test nuts having a different? They they might end up at the same value, but they might have a different intermediate value.
pawan:You're basically saying, test nets have a little more aggressive targets, that's all.
Parithosh Jayanthi:Yeah, exactly. So test nets could jump already to 20 blobs, for example, and on Mainnet we might just do 18.
pawan:Make, sense.
Ansgar Dietrichs:Is that something that it would be good to have L 2, or like, basically, if input from people that would want to test blobs at that kind of higher throughput level but whether for them that would be a headache or something, if if those there would be different values between the test nets and Mainnet? Or is that something that if you come comfortable wouldn't be an issue.
Parithosh Jayanthi:Yeah, I'm I'm not sure at the moment. It would be nice if we have people testing the higher throughputs on test nets as well, but I I guess, at least on testnet, we can just induce the load, if required.
Francis:I don't think there's any problem with testnet and many that have different configurations.
Francis:It's just mainly like for the higher throughput. There might be situations where we cannot submit blobs fast enough, but
Francis:like we can test that in testing as well.
Ansgar Dietrichs:Sounds good. Some principle, it seems like it might would be an option at least, to have testnets at at different numbers.
Ansgar Dietrichs:Do do we have people like, do we have opinions? So 1st of all, maybe pari, a question in terms of like, what? What do you see as the timeline for decision making on on the Bpo rollout strategy here, like, how how much more time would we have to make these decisions.
Parithosh Jayanthi:I think, until we start talking about test networks, we can essentially change our mind. It's a
Parithosh Jayanthi:config value that has to be changed and will likely be tied in with the releases that go out for test nets. So
Parithosh Jayanthi:I guess the next month.
Ansgar Dietrichs:Sounds good. So then, I think maybe today is primarily about flagging this topic. Getting a 1st round of busy people's
Ansgar Dietrichs:opinions and then, yeah.
Ansgar Dietrichs:taking it from there for for next Acdc, is there anyone else that like has specific like opinions on on kind of like initial rollout, like what one Bpo, as I put a chat like I personally kind of like to be 2 2 bpo's that already come with with the Fussaka rollout. But, like. Is there anyone else that wants to briefly present their opinion here?
Francesco:A more opinion, a question like, how if we did do this? Separate Bpo like not already scheduled in in Fusaka? How long after Fusaka. Do we think that that would need to be.
Parithosh Jayanthi:I think, at least on the data analysis side, we we try to have one week worth of useful data. And then it takes, let's say, 3 to 5 days to do a good high quality analysis on the data that we've collected.
Parithosh Jayanthi:And there's, I guess, one more caveat. I forgot to mention earlier with Fusaka. There's also some repricing that are required for increasing the gas limit, so that might be another
Parithosh Jayanthi:sort of parameter we're playing around with which leads to this
Parithosh Jayanthi:which leads to me at least, feeling more like we should be conservative because we're playing around with a lot of parameters at the same time.
Parithosh Jayanthi:But yeah, it it, I think in general, is about the release overhead and getting the community to upgrade. I would say, we're looking at like a 1. Ish 2 ish month time, 1, 1 and a half month. Timeline, I guess.
Ansgar Dietrichs:And and just to clarify there, basically because we would say we would decouple the throughput numbers on testnets from Mainnet, we would not have to 1st go through a full kind of update up upgrade cycle for all the test nets. Is that right?
Parithosh Jayanthi:I guess that's the question. Right now. We could, for example, bake in all 5 bpos and have the testnet sitting at 48 blobs, or whatever the upper limit we agree on is. And then we just have to do mainnet, because the test nets are already above the mainnet number.
Parithosh Jayanthi:I guess that would save us a few weeks worth of doing test nets first, st and then Mainnet.
Barnabas:I would actually recommend to bake in the and Bpo. One numbers in the minute releases. Once it comes to that.
Parithosh Jayanthi:Yeah, for sure. Yeah.
Barnabas:So like we wouldn't need to make a different release for Bpo one, and then for Bpo, 2 we could actually
Barnabas:reconsider and and see when it makes sense, and then give like 2 weeks
Barnabas:notice, to know the printers to like, roll up the new version.
Parithosh Jayanthi:Exactly so. That is the proposal that when we have the Fusaka releases, it comes with Bpo, one values as well as a timeline baked in, but not for Bpo. 2, 3, and how many ever we decide after.
lightclient:Is there a reason to not include
lightclient:2 and 3? As, like our optimistic values, we're planning to choose, like, I think the upgrade cycle is quite long for this type of stuff.
Parithosh Jayanthi:Yeah, I think that's the alternate approach. Then, we just pre select everything, and we decide to, let's say, abort or make another release to change the Bpo values. The question is, which approach do we want right now?
Parithosh Jayanthi:I personally feel like
Parithosh Jayanthi:agreeing to a number and then trying to change. It is messier than just agreeing to the number later.
Parithosh Jayanthi:But I can see both ways if we want to be really aggressive.
Ansgar Dietrichs:Yeah. And I think the good thing is, we don't have to decide that today. But I feel like, kind of it's already clear with the kinds of aspects that we have to weigh here against each other. Also the specific kind of turnaround time for a minute. I mean, put us on chat that
Ansgar Dietrichs:it's maybe a bit too optimistic to think that between client releases and mainnet hard fork we could ever do. 2 weeks might need a bit more for Mainnet specifically. But still, if we can skip the test nets, that still means that the turnaround time, for between client release and and Mainnet Fork would be unusually short at least.
Ansgar Dietrichs:Okay, any other comments on this topic for today. Otherwise, again, decisions we would make in 2 and or 4 weeks from now on, on the next one or 2 Acdcs.
Ansgar Dietrichs:Anything otherwise Bpo related that we would want to already have in mind for
Ansgar Dietrichs:for now in between for for devnets or anything basically anything about Bpo related that that is kind of short term, urgent.
kasey:One thing I brought up before was the idea of having a rollback built into the schedule where we we increase, and then we decrease just to make sure that that's a scenario that the system handles gracefully. And I think people push back on the idea of doing that in Mainnet but I think we should consider doing that in at least like sepulia like a a test net where there are things that aren't only El and Cl. Running.
Barnabas:I think we're gonna do that on hold team.
Parithosh Jayanthi:Yeah. So we have host key as an option for that as well as sepulia. Sepulia is also kind of a weird network, because basically, every validator is a super node purely because it's a very small network. And most people run all of their keys on one host.
Parithosh Jayanthi:So yeah, it's gonna have different patterns, anyway. So.
kasey:Yeah, I don't know if there's any validity to this, but I was also thinking about things outside of El and Cl, that might bake in assumptions about the schedule and that if any of those pieces
kasey:is fragile in a rollback scenario, it would be better to find that out when the network isn't already in trouble, was was my thinking. But not not gonna push too hard for that.
Dustin:I would continue to push back against this idea of of Bpo rollbacks as an emergency measure. It is never going to happen.
Dustin:We know we don't have the logistics for this in terms of the deployment or or coordination. Now you can argue that there are certain failure modes where it's like. It's kind of whipping along. And it turns out that we just kind of disenfranchised a few more nodes, and that then eip 7,870 really anticipated, and you know that I can see that kind of scenario. But the idea is something going seriously wrong and like no.
Dustin:no, please don't plan on that.
Dustin:It's not gonna happen.
Dankrad Feist:I was running back a Bpo different from just making another hard fork.
Dankrad Feist:I think like it's it's an equivalent thing, right just to some new client releases.
Dustin:Right. My point is not, of course, either is possible is that neither is an emergency measure. Neither is oops. We push too far too fast.
Dustin:you know. And now let's revert like this is my only point.
Dankrad Feist:I guess if it's not an emergency measure, then like it's also.
Dankrad Feist:then the Ppo is also just fine, like it works.
Dustin:But they work as well as each other.
Dustin:But but the the basic premise of as Prac. Here's what I'm getting at the basic premise of Let's as practice, for when we might want to do an emergency rollback, etc, etc, etc. Then, like No, I would stop there and say, that's we already screwed up really, really badly
Dustin:like that, that is, and and in a way that I is not going to be recoverable in that specific way is would be my would be my claim.
Dustin:So
Dustin:it's it's not that Bpos as a mechanism are worse than sort of ordinary hard forks. It's that the question is irrelevant to me.
Dustin:It speaks to an approach that is misguided.
Marius van der Wijden:Why?
Marius van der Wijden:Because.
Marius van der Wijden:like, if if we if we schedule something that is that is and we'll figure out, it's it's broken.
Marius van der Wijden:and we need to unschedule it right.
ethDreamer (Mark):I think I think, Dustin, you're essentially saying that we'd be more or less testing in prod like.
Dustin:Yes.
ethDreamer (Mark):Like we're we're raising it to a limit, we think is fine. We're not quite sure we're gonna let it be there for a little bit and then quickly switch back. And that's what you're objecting to.
Dankrad Feist:That's not what's being suggested. What's being suggested is using the
Dankrad Feist:previous race. The data from the previous race to like understand, if the next race is safe.
Dankrad Feist:I don't think the idea is to like 1st raise. Oh, it wasn't good. Now we're going back down that I don't think that is what's what we're suggesting.
Dustin:No, but but but the argument for doing that was as practice, for
Dustin:indeed doing it as a as an in case measure as I understood it. Maybe I misunderstood this, the proposal, but it was like before the claim or the statement. The suggestion was well, we might have to, and so we should find out first, st if some of these other sort of non elcl ecosystem entities react particularly badly to it. And let's do that before the the network is in crisis.
Dustin:That's that's why I'm reacting to.
Dustin:I'm not against testing it per se. I see Mary is just posted. What I am against is viewing it as a.
Ansgar Dietrichs:A particularly useful escape patch for the network planning as a whole or Vpo planning as a whole.
Ansgar Dietrichs:We have maybe to just jump in, because we have several people with raised hands, so maybe go by orders.
Potuz:Yeah. So I think you guys are having 2 separate discussions in parallel. So on the one hand, I think there, there was a suggestion of like shipping.
Potuz:2 Bpos separated enough so that we can recognize that the 1st one wasn't working as well as we respected the second one might be dangerous, and then that gives us time to
Potuz:call off the second one.
Potuz:and my understanding of I mean, and Casey was suggesting to have an emergency release that would just roll back the previous
Potuz:the previous Vpo and I kind of empathize. I mean, I I agree with the 1st approach, like we have we? We can schedule several of them as long as they're separated. We have enough time to call off the second one without any special mechanics, and I empathize with Dustin's point of view on rolling back and the mechanism to roll back. Because
Potuz:if a Bpo actually happens and it's an emergency situation, then any mechanism to roll back would be exactly the same as just like planning a new hard fork. It would require the same sort of release strategy, and it doesn't. I don't. I don't feel like it's we're gonna gain much by having an emergency mechanism to go back because it sounds to me like it's exactly the same as just a normal, hard fork.
Ansgar Dietrichs:Right Enrico.
Enrico Del Fante (tbenr):Yeah, to me, it's just we have now this mechanism that allows us to change things easier. So on one way
Enrico Del Fante (tbenr):it's it's wrong that we can say, Okay, based on this, we can then go go on main unsafely. And just because we have this escape patch that can
Enrico Del Fante (tbenr):use it. But anyway, if we, we have to schedule Bpos in A
Enrico Del Fante (tbenr):in steps right? So there is even a possibility where the previous Bpo is fine when the next one activates, we see some network degradation which is not catastrophic, but still degradation. And we can still plan for the next Bpo that goes that put the the blobs a little bit
Enrico Del Fante (tbenr):down. So we go back to a better situation, and we buy time to analyze things and improve. So
Enrico Del Fante (tbenr):I think, like there are. There is this possibility as well.
Enrico Del Fante (tbenr):It's not a full rollback. It's just scheduling something new and and lower down the numbers.
Ansgar Dietrichs:Makes sense any other comments on either this topic narrowly, or kind of Ppo strategy in general. Otherwise I would also bias towards trying to wrap that up, for now and then we should have that conversation actively Async, between now and Acdc. In 2 weeks, and then, maybe already in 2 weeks. We can
Ansgar Dietrichs:finalize our general strategy, maybe with value still pending for the testing or something. But basically general rollout strategy, I think 2 weeks from now would be a good time for
Ansgar Dietrichs:for decisions on this, but
Ansgar Dietrichs:for today, maybe if there's any further comments, then now would be the time. Otherwise that would move on
Ansgar Dietrichs:Shaba.
Csaba Kiraly:Yeah. So
Csaba Kiraly:from my point of view, the the kind of baking in too many values is is very much belief based.
Csaba Kiraly:And and we will have much more data later on. So I
Csaba Kiraly:I don't see a reason to to bacon too many of these, because we can go faster. We can do so, but it's good to agree on
Csaba Kiraly:on the timeline that we want to have. But but I think the baking in is is.
Csaba Kiraly:I just don't see the technical value in in baking in many values, scaling
Csaba Kiraly:because the many bottlenecks that can hit at every point of view. We will see and and we will learn from the mainnet. But we will learn also from tests in the meantime.
Csaba Kiraly:which we can scale up testing. So
Csaba Kiraly:it's not just learning from the previous bump. It's also more testing
Csaba Kiraly:on the higher levels and larger networks.
Csaba Kiraly:Yeah, so I would. I would just bake in one to close it.
Ansgar Dietrichs:Sounds good.
Ansgar Dietrichs:Yeah, I think. Then, yeah, on external code of sec, at least, we will talk about that.
Ansgar Dietrichs:And I think the different proposals are basic categories, either one Bpo baked in 2 Bpos baked in or multiple. And I think we've heard the different arguments already. So now it's about discussing it and coming to an agreement in 2 weeks.
Ansgar Dietrichs:Awesome. And then I don't see any further resistance. Shaba. If you could unraise yours.
Ansgar Dietrichs:then, yeah, then, let's move on to the. I think that was the last point that I had for Fusaka. Is there any other remaining Fusaka points that we would want to discuss today.
Ansgar Dietrichs:Okay, then we can move on to the Glam section. That one is a short section. We only have 2 items. The 1st one is just yet one more. Pr, that one is a very old one by Xiaoway that has been open for quite a while. The I think the
Ansgar Dietrichs:there was some
Ansgar Dietrichs:questions around what? What basically are the main blockers there? My understanding is that it would be a requirement if we ever wanted to in the future change slot times. I'm not sure if that's the only motivation for the Pr. I'm not sure if someone that has context on this. Sorry? The number is 3, 5, 1 0. You can already see in the number that it's a bit of an earlier one. If there's someone
Ansgar Dietrichs:here that has context on that, and could briefly say something about it.
Ansgar Dietrichs:put us.
Potuz:No one's raising hands. The original motivation comes from an eip a pr made on the spec. I think it was Yasik who's proposed it first.st That was about like rearranging this slot
Potuz:like changing the attestation, deadline, increasing it a little bit, realizing that we're wasting time with an idle node during aggregation and aggregation could be made shorter. That raised the problem, that the spec is phrased in terms of intervals per slot.
Potuz:And if we have, like a non symmetric slot, like the different intervals, have different timings. Then it would be better just to like, specify each of the deadlines in milliseconds instead of us an interval of the slot.
Potuz:and that's the original motivation for the eip, and it turns out that if we change the total time of the slot anyways, we would need this, and since this is a No. OP. For most clients, except perhaps, like dealing with configuration and dealing with the spec tests. It's a simple eip to merge as long as we don't change the this form of the slot, because essentially, clients don't need to do anything. That's why I believe.
Potuz:but I am in support of merging these assets.
Ansgar Dietrichs:Yeah, thank you. Is there? Basically, yeah, are there other clients have an opinion? Or to to ask the question, the way I did earlier, like, basically like, Is there any anyone who would be opposed to merging it as is?
Ansgar Dietrichs:And then Barnabas also asked the question, chat, maybe, is there anyone who would be opposed to, even if they maybe are okay with this being merged? Is, would there any be anyone who would
Ansgar Dietrichs:want to wait with merging this until we have full life on Mainnet.
Ansgar Dietrichs:Is this silence? Because everyone is okay with merging it? Or is the silence? Because no one else's context, because then otherwise, like, I would just say, we merge it.
Enrico Del Fante (tbenr):Yeah. The only concern, as as said, is some noise around configuration, and I don't know if there is possibility that we start breaking up a little bit. Some interrupt between
Enrico Del Fante (tbenr):clients like Mix, Vc. And Vn. Due to this configuration, changes floating around this the only risk that I see
Enrico Del Fante (tbenr):to waiting.
Enrico Del Fante (tbenr):Our troll fool.
Enrico Del Fante (tbenr):Is a reasonable argument.
Enrico Del Fante (tbenr):Even if I think that we, we have to go, we should go forward with this because it's a very basic thing that we have to do for everything else like slot and epbs. So we need to do that. So the
Enrico Del Fante (tbenr):the quick the better.
Enrico Del Fante (tbenr):But I see some noise.
Barnabas:Could you maybe target Amsterdam branches with this
Barnabas:spec so like any kind of Amsterdam
Barnabas:that we're gonna be launching, it would be built on top of this.
Barnabas:Would that make sense?
Barnabas:Because very, very shortly, we're gonna need to start doing the Instagram specific donuts also.
Barnabas:even probably before we hit follow, so I would most likely not wait till we hit. Follow to merge this line.
Enrico Del Fante (tbenr):So this is not going back to
Enrico Del Fante (tbenr):to phase 0 is something that enables on on a specific fork.
Enrico Del Fante (tbenr):Correct.
Barnabas:I think the config would go back to phase 0. Yes.
Barnabas:so like you would need to maintain a different branch that is able to read in a different config.
Barnabas:That would be your Amsterdam branch, or possibly an epbs specific branch.
Ansgar Dietrichs:Yeah, I'm a little out of the loop on this. This sounded reasonable. What Barnabas was saying just now is that a reasonable strategy, basically merging it for the glam saddam
Ansgar Dietrichs:branches.
Ansgar Dietrichs:I mean, if we even have porters and bannabas agreeing, then I think we can't really waste that opportunity. Yeah. Then, I think.
Ansgar Dietrichs:basically, if unless anyone wants to disagree, then I think that that's what we would want to, we we want to do here.
Ansgar Dietrichs:So merge it. But for for Amsterdam.
Ansgar Dietrichs:Okay, perfect.
Ansgar Dietrichs:And maybe last, just to double check is that, do you think that that's generally clear what that exactly implies for for people.
Barnabas:I think so.
Barnabas:I guess it's very clear for me, and
Barnabas:we're gonna be the ones doing the glimpse and testing as well. So it should be very.
Barnabas:very obvious for everyone. In my opinion.
Barnabas:it's just the question of what we want in Amsterdam. That's going to be the next question. I think.
Ansgar Dietrichs:Sounds good. Then let's.
danceratopz:Which is.
Ansgar Dietrichs:Basically for for the Glampson branches and
Ansgar Dietrichs:move forward. We only have one remaining agenda item, which is also for Glamsterdam, and it is a headliner proposal.
Ansgar Dietrichs:I think it's the last headline of proposal, because my understanding is that the deadline for proposing basically was, is over now, and this was the last one that basically made it in. So starting next Acdc, assuming that we basically do no longer too busy with Fusaka, we can then also open the discussion.
Ansgar Dietrichs:For for picking headliners for today. It was between primarily just the presentation. But yeah, Barnaby, I think you're on the call to talk about shorter slot times.
Barnabé Monnot:Yes.
Barnabé Monnot:Can you hear me? Well.
Ansgar Dietrichs:I can hear you. Well.
Barnabé Monnot:Okay.
Barnabé Monnot:Yeah, we've been playing with our proposal. We sent it in pretty late. So thank you all for letting me present.
Ansgar Dietrichs:And we can see your screen.
Barnabé Monnot:Okay, Zuko.
Barnabé Monnot:okay, this is a short presentation to drive home the point that shorter things are better. We're essentially trying to make the case for
Barnabé Monnot:moving to shorter slots for Glamsterdam in particular, moving from 12 second slots to 6 second slots, following an eap that was originally written by Ben Adams and Dunkrat, feist, and Julian and I joined more recently.
Barnabé Monnot:So why do we think 2 X shorter slots are very meaningful. The main message is that this makes ethereum l. 1
Barnabé Monnot:a better confirmation engine, which is essentially the main business of ethereum and its main value proposition to give some examples, it reduces transaction inclusion from 6 seconds on average to 3 seconds. It gives you 2 X censorship resistance from having 2 X block producers per unit of time.
Barnabé Monnot:It gives you lower dex fees for users from having less value picked up by arbitrages, and so more liquidity providers and so tighter spreads it accelerates finality. Time. If we don't change anything
Barnabé Monnot:from the consensus, from what it is today, like 13 to 19 min to something that's under 10 min.
Barnabé Monnot:There's many downstream interrupt ux and cost benefits. And there's even more good things that are detailed in the in the proposal.
Barnabé Monnot:So why make this proposal for Glamsterdam?
Barnabé Monnot:I genuinely think that shorter slot would be a great option to to consider slotting it in at the time that Amsterdam is expected to to be released, meaning, after we have ramped up to 48 blobs and to
Barnabé Monnot:hopefully a hundred 1 million gas limit.
Barnabé Monnot:I also think it's a good idea to make this proposal to accelerate conversations about it. I don't think shorter slot time is contentious. I think we all agree that generally we want to move in that direction, so I also don't think it's like distracting too much.
Barnabé Monnot:And I also think it's meaningful to have shorter slot in mind when thinking about the values restructuring proposal. So what I'm suggesting is to pipeline our thinking between the 2,
Barnabé Monnot:the 2 proposals.
Barnabé Monnot:How could we achieve it? So I've been. These are like very high, level straw men on the path to to implementation. Let's say, if we did decide to go with the route to include it in Amsterdam, I think we 1st need like a very serious study of attestation and aggregation propagation time in the Eip. The suggestion is 3 seconds for block propagation, 1.5 for attestation, 1.5 from aggregation.
Barnabé Monnot:There's a lot of anecdotal evidence out there that kind of make us reasonably confident that yeah, this is possibly workable. But I think we need to be. Yeah, just much more precise than this.
Barnabé Monnot:Then the second part is, there is a fairly large effort of just retrofitting the client and making the slot time conditional mainly because the chain has been running at some different slot slot time until now. So yeah, I understand that it's not like launching a new chain that just has 2 X slot times, like there's there's overhead that comes from this. And then, of course, testing to to make sure that everything works out
Barnabé Monnot:if we did not decide to do slot times in Glamsterdam, but instead to do that in Htar, and assuming that slot restructuring is what goes in Glamsterdam. So I think the path, then, is a little different. We obviously have a work of doing the slot restructuring, which involves
Barnabé Monnot:figuring out the right one, testing, etc. We may not need to be so precise about the attestation and aggregation propagation, time study just because some of the proposals. They pipeline this like they remove some of this stuff out of the hot path. And so, yeah, we may have an easier time figuring out like the right partitioning of the slot.
Barnabé Monnot:There is still, I believe, the work of
Barnabé Monnot:retrofitting the client with this, with this conditional logic, and then still, the testing that needs to happen for the for the slot time. Hard work.
Barnabé Monnot:One thing I want to point out is that over the last week, like we've been looking at the restructuring slots with the length of the shorter slot times, and it brought up some challenges and opportunities which some of them may be relevant. So maybe not. But I just want to point the high level points, because I think they're nice to have in mind. The 1st one is that whenever there are fixed overheads like one of them is, for instance, the attestation and aggregation round
Barnabé Monnot:that happens at the end of the slot. These fixed overheads. They get worse, obviously with shorter slots, because if their time is incompressible, then when you have shorter slots, you spend a higher relative share of the slot incurring these these costs
Barnabé Monnot:there may be more ways that are interesting to to get out of some of these fixed overheads like something we discussed a bit was the idea of
Barnabé Monnot:essentially unbundling or pipelining the head vote from the source and target votes, so that the aggregation can be moved out of the hot path. This is also something that we get in epbs with the Ptc. And the attestations being earlier.
Barnabé Monnot:And then another thing that I think came up quite a bit when we were discussing. This is this kind of trade-off that exists between the propagation time and the execution time and where we want to be on that frontier.
Barnabé Monnot:Yeah, that's it for me. Thank you for your consideration.
Barnabé Monnot:I'm seeing a very active chat. So sorry I did not see the messages. I think so.
Ansgar Dietrichs:Very primary clarification that people wanted was just that, basically by default. You would also argue for having the throughput per slot right to keep the throughput per time. Constant.
Barnabé Monnot:Correct. Yes, yes, so there are many that would need to be preserved. One of them is the throughput. Another one is the reward rate for stakers like, it doesn't mean you get 2 x, the issuance like you should still
Barnabé Monnot:keep that constant. So yeah, yeah, keeping everything equal unless there's a strong reason that by the time we move to this shorter slot
Barnabé Monnot:Fork, maybe we have scaling opportunities from for for different reasons, but all else equal. We would only want to change the slot time, and not like use that as a Trojan horse for making other changes. Yeah.
Ansgar Dietrichs:Mark, do you have a comment or question.
ethDreamer (Mark):Yeah, I'm I would just like to make some
ethDreamer (Mark):a general statement that I think is useful for everyone that's going to be participating in this debate. I've been participating in it since.
ethDreamer (Mark):since Bill and the bill interrupt, and it's been ongoing, and I just wanted
ethDreamer (Mark):say where I think the debate is from my perspective, and give people a chance to disagree on some just, very general statements, which is that, as far as I can tell, just based on where I I think there appears to be consensus that we want 2 things, and one of those is shorter slots.
ethDreamer (Mark):and the other one is some sort of slot, restructuring and pipelining.
ethDreamer (Mark):people are in various camps on that, but I think everybody wants both of those, and there is also consensus that we can't do both of those things in Glamsterdam itself. And so the debate
ethDreamer (Mark):is more or less about which form of pipelining, and which order to do these things in.
ethDreamer (Mark):so does anyone disagree with those general statements.
Barnabé Monnot:I agree with them? Yeah, yeah, I think I've heard, indeed, that doing both in the same work is not feasible
Barnabé Monnot:unless I see, like strong evidence to the contrary. I think I would make that assumption, and then I do think it's a matter of
Barnabé Monnot:1st selection of a restructuring proposal.
Barnabé Monnot:That's where I think, actually having the shorter slot. Timelines can be helpful, even if I also feel that the discussion has progressed quite a bit. And and we have like much higher confidence. So yeah, selection of a restructuring proposal and then ordering between
Barnabé Monnot:shorter slot time 1st or restructuring. First, st I think that's indeed the question. Yeah.
ethDreamer (Mark):I? Okay, I'm glad there's agreement, because I I see the things the same way. And
ethDreamer (Mark):from where I stand I want to get both of these things into ethereum as fast as possible.
ethDreamer (Mark):So I I think there's also one more
ethDreamer (Mark):point of agreement on a limited statement that
ethDreamer (Mark):you know, people may disagree about whether or not this restructuring, the the favored pre restructuring proposal is 7, 7, 3, 2. But I think at this point there is agreement that 7, 7, 3, 2, regardless of what other trade offs you might believe, offers maximal pipelining, meaning that for the same
ethDreamer (Mark):slot time you have more blobs and more blocks than competing proposals. And
ethDreamer (Mark):I think there's also agreement that you
ethDreamer (Mark):can have shorter slots from 7, 7, 3, 2 than you could for competing pipeline proposals.
ethDreamer (Mark):So I I those are all the statements. I believe that there is agreement upon.
ethDreamer (Mark):There may be others, but
ethDreamer (Mark):I'd like to give anyone a chance to to disagree with that if
ethDreamer (Mark):if that's not true, or if if yeah, you don't feel that.
Ansgar Dietrichs:Yeah. Enrico.
Enrico Del Fante (tbenr):I just want to make the argument. Why, I think the restructuring in the form of 7, 7, 3, 2 should go 1st
Enrico Del Fante (tbenr):is because the 7, 7, 3, 2 form
Enrico Del Fante (tbenr):is allowing us to decouple the consensus block from the payload and
Enrico Del Fante (tbenr):no matter, you see, so reducing the slot time, anyway, in some form reduce the network resiliency.
Enrico Del Fante (tbenr):So in my mental model going in that in buff first, st
Enrico Del Fante (tbenr):is wrong, because if you do the decoupling. First, st at least, you
Enrico Del Fante (tbenr):the argument is having is will be. We will have a much more resilience on the consensus layer, because the block will be much smaller, and the
Enrico Del Fante (tbenr):the instability might go only on the
Enrico Del Fante (tbenr):execution side of it, and we will have a much better consensus. Blocks flow, my dear.
Ansgar Dietrichs:Makes sense. Then, just a comment for me as a researcher, not not as host. Basically. Yeah, I, I, personally am not super opinionated in terms of the ordering of of these 2, I do think maybe just as a general comment, I think.
Ansgar Dietrichs:while yes, 772 epbs, like we've been talking about for a long time. I think we shouldn't just be too quick in being like. Okay, then, obviously, it should go first.st I think that's probably where we'll end up with, anyway. But I think at least, at least, it's good to like to take the moment of being like, okay, which of the 2 should go first.st
Ansgar Dietrichs:And
Ansgar Dietrichs:the the one thing that I would say is, even if we end up doing slot, restructuring slash epbs, or something like that. First, st it's still a good exercise to already do that while discussing what that would look like in terms of implications for shorter slot times.
Ansgar Dietrichs:And so in particular, Mark's comment, I think that basically, even for shorter slot epbs is optimal or close to optimal for actually making use of the window, and so actually is, in a way especially well positioned to then be shrunk later on. I think that's exactly the kinds of arguments we should look into
Ansgar Dietrichs:M, yeah. And
Ansgar Dietrichs:and and the one question I would maybe have for people is just to double check. We always say there's no world where we would ever combine these 2?
Ansgar Dietrichs:Are we certain? I mean sounds reasonable, and we should not do monster fox anymore. But is this something? We are 100% locked in on? Or is there like still a world in which these 2 could be in the same fork?
ethDreamer (Mark):I would love to combine them, but I've heard that Harry's head would explode so.
Ansgar Dietrichs:Yeah, we definitely don't want that.
Ansgar Dietrichs:Yeah, then let's continue with the comments, Ben.
Ben Adams:I would I would argue, if we can shorten the slot times.
Ben Adams:If that's a possibility, then that should go first, st because that has an immediate
Ben Adams:user experience impact. If we
Ben Adams:if we do delayed execution, that doesn't really change anything or epbs that doesn't actually change anything in the user experience.
Ben Adams:So I would argue for a shorter slot
Ben Adams:and then bring in epbs or delayed execution, or whatever to afterwards. To then allow us to start increasing gas again.
Ansgar Dietrichs:Mark.
ethDreamer (Mark):Yeah, I mean, I think the counterpoint to that. Is that like number one, we can't
ethDreamer (Mark):have as short slots as we can after epbs is before
ethDreamer (Mark):so like we may be able to get 6 seconds or sometime today, but we would certainly be able to do shorter after Eps
ethDreamer (Mark):so we could be like putting ourselves into a position where the slots are longer than they need to be if we do it. The other direction and
ethDreamer (Mark):I think.
Ben Adams:But you, but you've had. You've had that additional lag that you have to wait an additional hard fork before any any.
ethDreamer (Mark):You too.
Ben Adams:Very interesting.
ethDreamer (Mark):Data doing it, doing 2 2 forks where you change the slot. Time is
ethDreamer (Mark):like a lot of extra work. Now, we may not necessarily do 2 forks where we change the slot time, we may just say 6 seconds is fine, but even on top of that there's a lot of work around timing of various things that happen in the slot
ethDreamer (Mark):that, like handoffs is gonna need to do. And
ethDreamer (Mark):you know, if we did it the other way around. They're gonna need to do it twice. So even if we don't change the slot time twice, they would have to do those timings twice.
ethDreamer (Mark):So that's the main like, I think, basically, the main argument is to sum up something like
ethDreamer (Mark):we get to a world with both of these things slower, doing it the other way around, and
ethDreamer (Mark):maybe, and and getting to an optimal world where of even lower latencies is even slower.
Ansgar Dietrichs:Makes sense. Then, yeah, maybe one more quick one for me. I just wanted to agree to some extent with what Ben just said specifically from the scaling point of view. I understand Epbs has several benefits. Scaling is a big one, but not the only one, but in terms of scaling. Given that we just never really made scaling changes in ethereum in the past, or just for a long time. There is a bit of an overhang right now. So I think.
Ansgar Dietrichs:even without epbs in Glamsadam we would still, out of Glam Saddam, have quite a bit of extra headroom for scaling with access list. If we choose to do that, or and or with just general repricing that, give us more, remove some of the worst cases. So in terms of scaling. Given that we like, if we scale immediately by a factor of 5, there's no usage, anyway, to take immediate advantage of that. So I think, in terms of immediate impact, actually like
Ansgar Dietrichs:delaying and delaying the scaling aspect here until H. Star would probably not really be noticeable for users, because we already still have, like a smooth kind of scaling gradient, where shortest sometimes basically is the thing that otherwise you just don't have. So I do agree with Ben that just from a scaling point of view, basically like versus the benefits that shorter sometimes give, it might actually be that there's a more immediate benefit for users doing it this way around. But again, that's just a very partial argument.
Ansgar Dietrichs:Okay, that was last time for me making comments. Any other comments that obviously there's also quite a bit in chat if anyone would want to highlight anything out of chat for on the call.
Saulius Grigaitis | Grandine:So 1 1 thing I'm just wondering. Maybe there was already some study there done
Saulius Grigaitis | Grandine:what impact would be on the on the end users, because likely a lot of of these systems has a hard coded like a 2012 second slots there, and it could be a quite a big hassle for for these systems to to move to the new
Saulius Grigaitis | Grandine:slot time.
Barnabé Monnot:Yeah, maybe quickly on this. That's 2 things I've identified that might be important to look into is 1st systems like explorers. Them I feel like.
Barnabé Monnot:because there are chains that look like ours like gnosis chain that run at different slot times. There might already be like some infrastructure that is built that is flexible enough to change their assumptions.
Barnabé Monnot:There's probably still some that is not ready, and I think we should identify those. And the second thing is something that was also called out by Terence, and that's included in the headliner proposal. The possibility that some smart contracts may have hard coded 12 seconds
Barnabé Monnot:in in their behavior. That seems
Barnabé Monnot:also it's likely that there are some the changes to work
Barnabé Monnot:with proof of work which was viable slot time. So yeah, you would maybe limit the amount of
Barnabé Monnot:the ones. But now I'm seeing that photo says, actually, arbitrum contract itself has this hard-coded assumption. So yeah, okay, maybe there is something to be done. There.
Ansgar Dietrichs:Welcome!
ethDreamer (Mark):Yeah. So, wading more into, like my personal views on on the debate, I do think that
ethDreamer (Mark):in terms of the ordering of things like that. 7, 7, 3, 2 is just much more mature than shorter slot times for these kinds of considerations. And but I mean
ethDreamer (Mark):me personally, I would also, like
ethDreamer (Mark):my ideal world, is that we do? 7, 7, 3, 2, and we for sure do
ethDreamer (Mark):shorter slot times. The very next fork which would give of the
ethDreamer (Mark):stakeholders like the time to prepare for that.
ethDreamer (Mark):and and could potentially be like developed in parallel the way that Electra and Fushaka were.
ethDreamer (Mark):if we know what the headliner is, we can do it in parallel.
Ansgar Dietrichs:Yeah, just because I've heard this concern about, I mean, obviously, like 7, 7, 3, 2 already has the benefit of actually like not just being specs, but but but having having been implemented and and so on in terms of just the general implementation, complexity, testing, complexity of shorter slot times, this has been brought up in the past as a concern for even general Glam. Stamp viability?
Ansgar Dietrichs:Are there people that that have opinions and views on, independent of the ordering, and whether we want to do it in Glamsterdam. But like how realistic it would be for shorter slot times to be in Glamsterdam.
Ansgar Dietrichs:as he put us in chat, saying a lot of work, but doable.
Ansgar Dietrichs:yeah, put us.
Potuz:So I don't know. I gave enough time to Preston to express his opinion on this. He's the one that's been working on this. It's been working for a few weeks and has a branch that is already passing tests and compiling at least a lot of things that need still to be changed from the point of view of the code base is not something. I mean, people think we just have this constant that you need to change, and that's it.
Potuz:But the second order effects are huge. We have a lot of timing places where you need to deal with like, are we going to reorg this block or not. Is this block actually late? Are we counting attestations for the next slot early or not, because we made a bet that we will reorg this block. And then we decided that this block is not weak. We need to reorg it back.
Potuz:We have cache that those cache has timing expirations. So when are we pruning those cash? We have optimistic syncing that is affected by this. That is one of the largest, most complicated pieces of code. On the Cl side, we have 4 choice that actually should take tracks of timing to decide whether or not the head is is weak or not. So this, besides the blockchain part of it.
Potuz:There's so many places that the slop time changes affect that. It's going to be quite, quite hard to
Potuz:test. However, having said so, I believe if the choices is, I mean I'm I'm of course I'm against having this in Glamsterdam, but I believe that it can be done in a single fork if it's chosen to be one one pr. It's just that. I think that the the number of things that need to be tested, the number of teams that need to be called that. It's it's just daunting to even start thinking about it.
Ansgar Dietrichs:Annabe.
Barnabé Monnot:Yes, yeah, yeah. I agree with Potus. My
Barnabé Monnot:question is, how much of that is just fixed work that we have to do, no matter what like, even if we were to restructure first.st
Potuz:All of it. So we are already working on it because we believe that we are going to ship this. And that's why, we started working on this
Barnabé Monnot:Okay.
Potuz:We will have to do this, anyways.
Barnabé Monnot:Yes, right? Right? Yeah. Yeah. So then, it's really a matter of
Barnabé Monnot:something is more ready now. So we might as well ship that 1st and have this big bundle of work like pipelined with the thing that is more ready. I I think that's reasonable.
Barnabé Monnot:I still to me like, yeah, from my viewpoint.
Barnabé Monnot:the sequence of operation that makes sense from a feature. Perspective is really shorter, slot time 1st and then restructuring. So there's a difference in opinion. Kill, of course.
Barnabé Monnot:But yeah, yeah, I do think
Barnabé Monnot:highlighting the extra overhead of doing, shortening 1st and then restructuring would be helpful to the, to the discussion as well.
Barnabé Monnot:What Barnabas asked in the chat essentially.
Ansgar Dietrichs:Right?
Ansgar Dietrichs:yeah, is there anyone with a specific opinion on on that specific question that Bannabas just put in chat, what's the implementation time basically of the 2 different orderings here, if we do. Ep, based 1st and then lower slot times or the other way around, basically, is there anyone that thinks that
Ansgar Dietrichs:just in terms of implementation time, the ordering here matters for those.
Potuz:Yeah, that was the argument that Mark was making. That we seem to disagree. But I don't understand why, because to me this is a no brainer testing the
Potuz:timings on this. Within the slot is going to have to be done and benchmarking. This is going to have to be done twice instead of once. So certainly there's an obvious testing overhead by shipping slot times earlier.
Potuz:So shipping epbs earlier has less impact on the testing team.
ethDreamer (Mark):Yeah. So to clarify
ethDreamer (Mark):it, we we are of the opinion that in getting both of these things into ethereum it's long to do, it will take more time doing it the other way around. When you wanna
ethDreamer (Mark):look at I don't. I don't know that.
danceratopz:Do anything.
ethDreamer (Mark):Okay, unfortunately, it has any impact.
danceratopz:But.
Ansgar Dietrichs:Can we have someone mute then?
Ansgar Dietrichs:That? Oh, that that this account that's unmuted
Ansgar Dietrichs:perfect. And okay. Then sorry I didn't want to drop you then, in terms of so because again, like, the idea is not to for today to make decisions. We also kind of only wanted to mostly highlight. This proposal have some light initial discussion just to highlight the questions or areas of disagreement. I think that probably we did quite well now
Ansgar Dietrichs:and then the idea would be again in 2 weeks if if we are still very busy with kind of with Fusaka, that depends a little bit. But in principle. If we have the room, then we will really kind of go into into the discussion of what what we should prioritize for Glam Saddam in 2 weeks, and so ideally kind of people that have
Ansgar Dietrichs:had disagreements on on this topic that were highlighted just now should take the next 2 weeks to basically iterate on that. And so that we we have the most information possible for for starting that discussion in earnest in 2 weeks.
Ansgar Dietrichs:Perfect. Then, I think, unless there's any remaining comments, anything that was is urgent that we need to discuss right now. We have only a few minutes left, anyway, but I think we otherwise finished with the agenda
Ansgar Dietrichs:any remaining of topic?
Ansgar Dietrichs:If not, then. Yeah.
Ansgar Dietrichs:thank you very much. It was great to host these 2 O'confs, and also happy to have the professionals take back over next week. See you all next week. Bye.
Potuz:Bye-bye.
Justin Florentine (Besu):See you did great Anskara.
Ansgar Dietrichs:Thanks.
Barnabé Monnot:Great job on scale.
Chat Logs
00:00:45
Ansgar Dietrichs:https://github.com/ethereum/pm/issues/1579
00:03:33
nixo:https://testinprod.notion.site/Sunnyside-Devnet-Updates-06-23-Internal-21b8fc57f54680639103d8b54c5f1500
00:06:34
Barnabas:Please note, berlinterop-devnet-2 is going offline by end of today!
00:06:37
Ansgar Dietrichs:https://github.com/ethereum/pm/issues/1579#issuecomment-3005918568
00:07:52
Ansgar Dietrichs:First PR: https://github.com/ethereum/consensus-specs/pull/4393
00:08:02
Manu:Peer sampling replaced by custody sampling
00:08:16
Francesco:Replying to "Peer sampling replac..."
Yeah I’d say it’s pretty orthogonal to validator custody
00:08:42
Barnabas:Anyone opposing merging this in?
00:09:06
Dustin:Replying to "Peer sampling repl..."
fair enough
00:09:12
Manu:Replying to "Anyone opposing merg..."
Go nuke
00:09:18
Enrico Del Fante (tbenr):Go delete
00:09:38
Ansgar Dietrichs:Second PR: https://github.com/ethereum/consensus-specs/pull/4394
00:11:02
pawan:In favour of merging this PR from lighthouse. It’ll be helpful for different sync strategies we are trying as well
00:11:59
Ansgar Dietrichs:Third PR: https://github.com/ethereum/consensus-specs/pull/4406
00:12:35
Barnabas:can we get a few more thumbs up on each PR pls?
00:12:46
Barnabas:so its gonna be a bit nicer to merge them in
00:13:26
ethDreamer (Mark):Oh lol you might have said “that has” and I heard “lighthouse” 😂
00:13:30
Enrico Del Fante (tbenr):Good to go
00:13:44
Barnabas:sendit
00:14:58
Barnabas:If its not in FULU it should be gone
00:15:24
Barnabas:maybe we can have a “feature_request” spec, that are optional to implement
00:16:07
kingy_sigp:if you're speaking for Jimmy from LH he's fine to lose it
00:16:24
Barnabas:I personally think, if at least one client is implementing, then it should be kept.
00:16:53
Dustin:Replying to "I personally think..."
is this the case though
00:16:59
Francesco:Replying to "I personally think, ..."
No it’s not
00:17:06
Barnabas:Replying to "I personally think, ..."
Jimmy said he might be looking into it
00:17:12
Francesco:Replying to "I personally think, ..."
I don’t think for Fulu though?
00:17:24
pawan:Replying to "I personally think, ..."
No we aren’;t implementing it either
00:17:26
Barnabas:Replying to "I personally think, ..."
I’m not sure if it was for fulu
00:17:35
Barnabas:Replying to "I personally think, ..."
then yeet
00:17:53
Barnabas:Replying to "I personally think, ..."
we can always reintroduce for future das versions
00:18:05
Ansgar Dietrichs:Fourth PR: https://github.com/ethereum/consensus-specs/pull/4407
00:18:36
Barnabas:Kasey approves
00:20:26
Barnabas:ACDE - 4 new EIPS
ACDC - 4 PRs merged
Ansgar is on 🔥
00:21:21
Francesco:Replying to "ACDE - 4 new EIPS
AC..."
Sounds like a yes man if you ask me
00:22:18
Parithosh Jayanthi:So with the PRs merged, we are ready for Fusaka?
00:22:28
Parithosh Jayanthi:Pending findings while testing ofc
00:24:48
Parithosh Jayanthi:LFGGG!
00:25:08
Francesco:Time is over
00:25:10
lightclient:isn’t that a fast timeline for devnet 3
00:25:15
Barnabas:Ansgar ships
00:25:18
Marius van der Wijden:Wbat
00:25:26
Marius van der Wijden:*what does frozen mean?
00:25:32
Barnabas:Replying to "*what does frozen me..."
no more CL changes
00:25:47
Barnabas:Replying to "isn’t that a fast ti..."
lets see how the repricing goes on the EL side
00:25:55
Parithosh Jayanthi:Replying to "*what does frozen me..."
And we can spend money on more expensive devnets without worrying about specs changing every week
00:26:03
Ansgar Dietrichs:https://blog.sigmaprime.io/shipping-peerdas.html
00:26:31
Barnabas:BPO is a diff topic than spec freeze imo
00:28:18
Barnabas:proposed BPO1 value was: 9/12
00:28:31
Ansgar Dietrichs:Replying to "BPO is a diff topic ..."
right, sorry, I might not have clearly expressed that
00:28:45
pawan:So ship Fusaka with same max_blobs as electra?
00:28:55
Barnabas:Replying to "So ship Fusaka with ..."
yes
00:28:59
kasey:Replying to "So ship Fusaka with ..."
+1
00:29:08
pawan:Replying to "So ship Fusaka with ..."
Agree its better to be conservative
00:29:19
Manu:Replying to "So ship Fusaka with ..."
+1
00:29:22
Ansgar Dietrichs:Replying to "proposed BPO1 value ..."
3:4 is a somewhat extreme ratio, I'd prefer 8:12 (if we want 12 max)
00:29:46
Barnabas:Replying to "proposed BPO1 value ..."
also good, CL devs only care about MAX not target anyway 😄
00:30:12
Potuz:Replying to ""
we care about target
00:30:14
Potuz:Replying to ""
not max
00:30:22
Potuz:Replying to ""
target is what determines the sync safety
00:30:28
Manu:Replying to "proposed BPO1 value ..."
We care about both actually
00:30:30
Enrico Del Fante (tbenr):Makes sense to just activate fulu and then rise later via BPOs. go slow at BPO1 and then be more aggressive later LGTM
00:30:41
Barnabas:Replying to "proposed BPO1 value ..."
you read in the max only from the config 😄
00:30:49
Barnabas:Replying to "proposed BPO1 value ..."
you have no idea what target is
00:31:01
Ansgar Dietrichs:I personally would like to have 2 BPOs bundled with Fusaka:
Fusaka (6/9, no immediate bump)
BPO 1 (8/12, the week after)
BPO 2 (12/18, 1-2 months after)
that way, we would have proper time for analysis and rolling out the next batch of BPOs, without too much dead time on mainnet with still Pectra-like throughput values
00:31:39
Barnabas:I’d do one testnet with same as mainnet tho
00:31:40
Enrico Del Fante (tbenr):As long as testnets are more aggressive, it’s fine 🙂
00:32:16
Manu:Replying to "proposed BPO1 value ..."
We have no idea what the target is, agree, but the target, for example, has an impact on the total DB size for blobs.
00:33:10
Manu:Replying to "proposed BPO1 value ..."
And we care about max for P2P issues, disk write speed concerns etc…
00:34:43
Justin Florentine (Besu):it's more about cutting a release overhead
00:34:58
Francesco:Replying to "it's more about cutt..."
Yeah that’s what I meant mostly
00:35:06
Barnabas:I think the mainnet release should have fulu and bpo1 baked in
00:35:08
Potuz:You need a few weeks between announcement and upgrade
00:35:13
Justin Florentine (Besu):Replying to "it's more about cutt..."
analysis plus 1-2 weeks
00:37:23
Barnabas:I think it also depends on when we ship fulu :D
00:37:46
Marius van der Wijden:I would bake in the 2 first bpos in fusaka, do the rest later
00:38:42
Matthew Keil:We should only bake in 1. There is no replacement for network traffic to tax a node and its important to see the effects on overall node health before we raise aggressively
00:38:57
Justin Florentine (Besu):i'm mostly aligned with pari, am open to 2 bpos included, but i do think the decision on how many to include is informed by how the first one goes.
00:38:58
Parithosh Jayanthi:options:
Bake in BPO1
Bake in BPO1&2
Bake in BPO[1-5] and then abort if needed
00:39:06
Csaba Kiraly:I would bake in 1
00:39:08
Barnabas:We gonna do that on testnet only not on mainnet
00:39:34
Matthew Keil:Testnet traffic is insufficient to really see how a node will perform
00:39:41
Potuz:Replying to "I would bake in the ..."
I agree with this with the caveat that the second BPO should be scheduled with several weeks/months from the first so as to be able to roll it back if the first one doesn't work well
00:39:52
lightclient:Replying to "I would bake in the …"
^^^
00:39:53
Enrico Del Fante (tbenr):Replying to "We should only bake ..."
Unless there is at least 1 month between BPO1 and 2
00:39:55
Justin Florentine (Besu):what if we bake in 2 and bpo 2 is a return to pectra blob rate?
00:40:00
Dustin:if a BPO has gone wrong it's kind of too late, depending on how it goes wrong. The moral hazard here is people looking at a rollback built in and seeing it as license to be too aggressive
00:40:12
Barnabas:Replying to "what if we bake in 2..."
would really not want to have this on mainnet.
00:40:35
pawan:Replying to "what if we bake in 2..."
Why would we want to do this?
00:40:54
Justin Florentine (Besu):Replying to "what if we bake in 2..."
i mean if bpos are up only why are we testing them on devnets?
00:41:13
Barnabas:Replying to "what if we bake in 2..."
The mechanism has to work.
00:41:24
Justin Florentine (Besu):Replying to "what if we bake in 2..."
why if we never use it in prod?
00:41:54
Csaba Kiraly:For the 2nd bum, I think it is better to have a target we aim for both in number (2x) and timeline (2 months), but evaluate it before committing to the number.
00:41:56
Barnabas:Replying to "what if we bake in 2..."
I think it could in theory be triggered
00:41:59
Francesco:If BPOs are scheduled gradually enough, it should be possible to do it? Like, if it takes 2 months for throughput to go from fine to not fine
00:42:26
Francesco:Replying to "If BPOs are schedule..."
But yes, don’t think we should schedule values that we are not quite comfortable with
00:42:29
pawan:Replying to "If BPOs are schedule..."
Depends on the numbers too
00:42:34
Csaba Kiraly:Replying to "For the 2nd bum, I t..."
That allows us to be both more conservative and more aggressive based on tests. Tests that we don’t have at the moment.
00:42:38
Barnabas:Replying to "For the 2nd bum, I t..."
how do you evaluate something that you have no way to verify ?
00:43:07
Csaba Kiraly:Replying to "For the 2nd bum, I t..."
We can do much more verification that we’ve dine till now, that’s clear.
00:43:52
Justin Florentine (Besu):@Ansgar Dietrichs you have hands to call on
00:44:08
Marius van der Wijden:I think we should test it...
00:44:33
Ansgar Dietrichs:Replying to "@Ansgar Dietrichs yo..."
oh, sorry
00:44:44
ethDreamer (Mark):Sorry maybe I don’t understand the proposal
00:45:01
kasey:Replying to "If BPOs are schedule..."
People have been talking about bumping minimum 3 at a time, but I do prefer the idea of a schedule with many single blob increases vs fewer 3-at-a-time increases.
00:45:11
pawan:Replying to "I think we should te..."
Test reducing the max_blobs? We are already doing that to test the mechanism
00:45:55
Marius van der Wijden:Replying to "I think we should ..."
I agree with you Dustin, that we should not think of reducing the BPO as anything but an emergency fork
00:46:57
Ansgar Dietrichs:right, so for clarity, these are separate topics
cancel a pre-scheduled BPO fork, by having new client releases without that BPO
roll back a BPO fork after it happened, by having a new release with another BPO fork that returns back to old / otherwise lower parameters
00:49:58
Justin Florentine (Besu):Replying to "I think we should te..."
if you think of it as an emergency procedure, i don't think testing it on devnets is sufficient to trust it for mainnet.
00:50:11
kasey:This raises an issue with the nfd disconnection behavior. As the network rolls out a bpo schedule change, nodes will disagree on the nfd.
00:50:25
kasey:Replying to "This raises an issue..."
We don’t want to fragment in this scenario.
00:50:29
Justin Florentine (Besu):Replying to "I think we should te..."
it's like testing your life preserver by throwing it in the tub. then taking it out to sea.
00:51:01
Potuz:the original motivation was to rearrange the slot
00:51:11
Ansgar Dietrichs:PR: https://github.com/ethereum/consensus-specs/pull/3510
00:51:12
Francesco:Replying to "This raises an issue..."
But they wouldn’t disconnect until the bpo fork epoch, no?
00:52:09
kasey:Replying to "This raises an issue..."
Imagine you are the node that has not upgraded and you’re at the end of the schedule. You disagree with a potential peer’s nfd and the epoch in question has already passed, so you would disconnect.
00:52:48
Barnabas:Replying to "PR: https://github.c..."
anyone opposed merging this in before we hit fulu?
00:53:08
Csaba Kiraly:@Justin Florentine (Besu) Indeed, the test there is not what we want.
What we would need is to first drive it over the limit, and then try to save it by reducing it.
The problem is that “over the limit” can mean many possible failure modes, and some of those we can’t test, or at least we did not yet thing thrugh how to test.
00:53:14
Francesco:Replying to "This raises an issue..."
Right but isn’t that the behaviour we want at that point? It would be fine if the bpo schedule change was rolled out sufficiently in advance
00:53:48
Barnabas:Replying to "This raises an issue..."
nfd issues would be raised during devnets
00:54:03
Barnabas:Replying to "This raises an issue..."
highly unlikely we would have an emergency release faster than 256 epochs
00:54:41
Justin Florentine (Besu):Replying to "I think we should te..."
i understand that, i just don't want to be in a situation where we need to consider bpo limit going down, and we have only tested the mechanic on devnets. devnets are very contrived.
00:55:18
Potuz:there's no real reason to have this pre-fulu so it seems reasonable to me to have this for Glamsterdam branches
00:55:37
Potuz:agreeing with @Barnabas for the first time in my life
00:56:08
kasey:Replying to "This raises an issue..."
Isn’t that the behavior we want
I suppose we would set the epoch of the bpo to reduce to a value right after the epoch where the true limit was overshot, so you’re probably right.
00:56:16
Barnabas:Replying to "agreeing with @Barna..."
either I’m becoming more wise, or you starting to lose your edge 😂
00:56:40
Justin Florentine (Besu):Replying to "I think we should te..."
because what is gonna happen in the happiest situation, is that home stakers can't keep up with blob propagation, and they complain. if bpo is up only, we have no option to help them.
00:57:01
Csaba Kiraly:Replying to "I think we should te..."
I agree with you. What I was saying is that going down is not tested currently for the situation we would try to use it for.
00:57:07
Barnabas:glamsterdam be built on top of 3510 basically
01:00:20
Barnabas:is the plan to half the attestation rewards with halving the slot time?
01:00:32
Ansgar Dietrichs:Replying to "is the plan to half ..."
yes
01:00:48
Ansgar Dietrichs:Replying to "is the plan to half ..."
basically, idea is always to keep rewards per time constant
01:01:25
Potuz:Replying to "is the plan to half ..."
can we sneak also a lower issuance in the EIP?
01:01:33
lightclient:is 12->6 sec reduction enough to be that useful for confirmation? 6 sec is still fairly slow, it doesnt remove the need for faster out of protocol confirmations
01:01:36
Barnabas:Replying to "is the plan to half ..."
that would kill it 😄
01:02:55
Manu:Does it go along with gas limit halving? (If not, we are going to x2 gas/sec)
01:03:13
Barnabas:Replying to "Does it go along wit..."
yes
01:03:14
Ansgar Dietrichs:is this a sneak proposal for having canonical emojis for hard forks?
01:03:22
Francesco:Replying to "Does it go along wit..."
Gas/s should stay constant (or slightly lower) unless we happen to think we want to increase it at the same time, for other reasons
01:03:30
Marius van der Wijden:We would also need to half gas limit and half #blobs per block. Halving blocktimes also means we might not have some of the amortization effects that we benefit from right now
01:04:11
Barnabas:we even gonna be able to test BPO value reduction in prod :D
01:04:11
Marius van der Wijden:Replying to "We would also need..."
On the other hand, some worst cases grow superlinear with gas limit
01:04:22
Katya Riazantseva:for shorter slots metrics specs seem to be even more valuable. Testing will be tough
01:04:37
Ansgar Dietrichs:Replying to "We would also need t..."
right, shorter slots are explicitly never a scaling strategy. if anything, they will usually slightly lower throughput overall
01:04:38
Justin Florentine (Besu):Replying to "Does it go along wit..."
wat. that needs to be explicitly mentioned pls.
01:05:00
Ansgar Dietrichs:Replying to "We would also need t..."
I am not convinced there are enough such superlinear cases for that argument to really matter
01:05:01
Ben Adams:Replying to "We would also need t..."
Proposal includes halving everything
So same per second
01:05:06
Csaba Kiraly:I think shorter slot times are more about granularity than anything else. Most throughput like metrics are not changed. It is the granularity and as a consequence inclusion delay that gains.
On the flip side there is the overhead generated by this granularity.
01:05:25
Barnabas:I think 6s slot time gonna happen sooner or later, the question is do we want epbs/delayed execution before or after 6s slot time. (Doubt we can do both in the same fork)
01:05:44
DA | Flashbots:What’s the evidence you’re using that cutting the first part of the slot from 4s —> 3s is something local builders can handle?
01:05:50
Parithosh Jayanthi:^ also if the specs and changes are understood well enough for a fork that can happen ~6mos after fusaka
01:05:58
Anders Kristiansen:given we are moving towards enshrined zkEVM, this should be aligned with real-time proving, no?
01:06:06
Dankrad Feist:Replying to "is 12->6 sec reducti..."
It's definitely already a major step for several metrics but part of the value would also signalling that we care about this and will continue trying to lower slot times as far as possible
01:06:26
Sophia Gold:Replying to "given we are movin..."
There's no significant conflict
01:06:45
Julian Ma:Replying to "What’s the evidence …"
The throughput would be halved and the propagation time less than halved so I don’t see a clear conflict for local block builders, in fact it may be easier to propagate a full block as you have more time for less data
01:06:46
Dankrad Feist:Replying to "Does it go along wit..."
It is explicit in the EIP
01:06:58
Marius van der Wijden:Replying to "given we are movin..."
Why? It would require another 2x from provers?
01:07:13
Julian Ma:Replying to "What’s the evidence …"
There is of course overhead which we would need to study better
01:07:13
lightclient:which order is currently leading
01:08:03
Ansgar Dietrichs:we can say ePBS* (pronounced epbs-star) instead of “slot restructuring”, meaning ePBS or something close to it :-)
01:08:07
Julian Ma:Replying to "given we are moving …"
Time required for proving is pretty much linear in the gas used in a block. Since this proposal doesn’t increase gas/s, proving time isn’t affected
01:08:10
Sophia Gold:Replying to "given we are movin..."
No, it wouldn't. They're only slightly sublinear in gas per block
01:08:11
Csaba Kiraly:I think shorter slot times should come with two important techniques:
Pipelining
Techniques to make reorg or skipped slots cheaper
This is because shorter slot times by definition increase the probability of such events happening, so we should reduce the relative cost of these.
01:08:19
Marius van der Wijden:Replying to "which order is cur..."
Not a CL dev, but I think slot restructuring should go first before slot shortening
01:08:45
Dankrad Feist:Replying to "What’s the evidence ..."
Can you explain why they could not handle it? 3s should be plenty of time to build and propagate, afaict all of the missed slots are due to blocks being built late and not local builders who build on time
01:09:31
Barnabas:Have we considered doing anything other than 6s?
01:09:45
Sophia Gold:Replying to "I think 6s slot ti..."
Delayed execution shouldn't conflict with shorter slot times
01:09:49
Ansgar Dietrichs:can’t wait to call on myself in a sec
01:10:08
Marius van der Wijden:Replying to "Have we considered..."
Lets do 10 minutes
01:10:10
Barnabas:Replying to "I think 6s slot time..."
In terms of code change it does
01:10:24
Marius van der Wijden:Replying to "Have we considered..."
Parity with BTC
01:10:45
Barnabé Monnot:Why does shorter slot times decrease network resiliency? assuming there is p99 confidence on things arriving on time
01:10:52
Sophia Gold:Replying to "I think 6s slot ti..."
Why?
01:10:53
DA | Flashbots:Replying to "What’s the evidence ..."
imo the pipeline is slower than people realize + overhead from mevboost, so this probably kills any form of min-bid etc.
01:11:09
DA | Flashbots:Replying to "What’s the evidence ..."
local builders look much healthier than they actually are because of how small their blocks are.
01:11:11
Dankrad Feist:Replying to "I think shorter slot..."
missed slots only incur an opportunity cost, no penalty. Since the proposal will halve gas and rewards it will also halve the opportunity cost
01:11:34
Francesco:Replying to "I think 6s slot time..."
In principle delayed execution can be an EL change only, which doesn’t interact much with shorter slot times. On the other hand, right now most of the slot restructuring proposals are actually CL heavy
01:11:35
thomasthiery:If Glamsterdam discussions have started I’d like to also encourage people to think about FOCIL fits in the slot restructuring/slot shortening picture
fwiw I think it’s compatible with both, but it can be considered part of slot restructuring imo
01:12:03
Sophia Gold:FYI, Vitalik's suggestion for testing this was a network with existing geographically distributed ethstaker types showing they don't miss more attestations
01:12:05
Dankrad Feist:Replying to "Have we considered d..."
the original proposal was 8s, but I think it's not ambitious enough. Right now it looks like 6s should just work out of the box
01:12:09
Justin Florentine (Besu):YES. lots of interactions between slot/de/focil
01:12:16
Barnabé Monnot:To mark’s point on whether 7732 is the optimal form for shorter slots: imo it's likely close, I want to increase my confidence on it however
01:12:29
Potuz:Replying to "If Glamsterdam discu..."
+1 I think any decision that is made that changes the slot should be made in the same fork or at least forward compatible with FOCIL
01:12:32
Toni Wahrstaetter:pipelining + shorter slots 🤝
The question will be, do we want/need max pipelining in the form of ePBS which also comes with significant complexity, or are we fine with getting 70-80% of the pipelining - doing the delayed exec 7886 proposal.
7886 in its current design could be a small step towards full ePBS, removing PTC, unconditional payment and block-payload separation.
01:12:42
Parithosh Jayanthi:Replying to "FYI, Vitalik's sugge..."
We already have this via xatu data, there’s no need for another network
01:12:49
lightclient:is the ux that noticeable for users though?
01:12:59
Parithosh Jayanthi:Replying to "FYI, Vitalik's sugge..."
Or is this for testnets? You run into the issue of needing larger state/etc to be realistic
01:13:06
Potuz:Paying less on tx sounds like a lot of UX benefit to me
01:13:24
lightclient:epbs makes txs cheaper?
01:13:33
Barnabé Monnot:Replying to "is the ux that notic..."
this is one of many other benefits. but yes it is also quite visible. users wait 2-4 seconds before thinking sth is wrong. this puts the average inclusion latency around these numbers
01:13:34
Potuz:yes
01:13:36
Ansgar Dietrichs:Replying to "can’t wait to call o..."
oof having an opinion section now really ruins this host thing
01:13:50
Potuz:you get to have many more blobs and higher gas limit on execution
01:14:19
lightclient:ah okay i see
01:14:23
Dankrad Feist:Replying to "is the ux that notic..."
I think halving confirmation time is very noticable?
by this argument, we should just do no scaling or slot time assumptions because none of them are enough?
01:14:25
Potuz:Replying to "epbs makes txs cheap..."
^^^^^^
01:14:28
Sophia Gold:Replying to "FYI, Vitalik's sug..."
I think the idea was a long running testnet. It would be significant work, but I assume some people may not be convinced by the xatu data alone
01:14:30
Barnabé Monnot:Replying to "Paying less on tx so..."
it’s not either/or 🙂
01:14:32
Ansgar Dietrichs:Replying to "epbs makes txs cheap..."
it (unironically) does! like any slot restructuring though
01:14:43
Ansgar Dietrichs:Replying to "epbs makes txs cheap..."
it does it quite well though
01:14:59
Dankrad Feist:Replying to "is the ux that notic..."
I think we should 6s first, then 4s, and then an upgraded consensus that gets us to 1s eventually
01:15:15
Sophia Gold:Replying to "epbs makes txs che..."
Does anything include the problems with PBS?
01:16:55
Dankrad Feist:I think talking to many stakeholders, shorter slot times bring the more immediate benefits vs scaling as ansgar said
(eventually need to do both)
01:17:50
Potuz:There are actual contracts that need to change, Terence identified the Arbitrum contract
01:18:01
Barnabas:EL explorers don’t care.
BN explorers are few and rare, Dora will probably support it before any CL supports it :D
01:18:06
Ansgar Dietrichs:Replying to "I think talking to m..."
maybe we’d need to bring some of these stakeholders into acd then or have some sort of breakout on that topic, because I think the need / benefits of shorter slots have historically not been super legible to the core dev process
01:19:11
Potuz:FWIW PReston is already working on a branch to shorten slot times
01:19:17
Potuz:it's a lot of work but doable
01:19:25
Potuz:it touches a lot, a lot of things
01:19:40
Barnabas:Replying to "FWIW PReston is alre..."
wen shorter slot-time devnet?
01:19:59
Barnabé Monnot:would like to understand really how much work it is for all stakeholders, if we did decide to do shorter slot times first, is this really unmanageable?
01:20:16
Barnabé Monnot:Replying to "would like to unders..."
and how much “wasted” effort vs restructure -> shorten
01:21:01
Parithosh Jayanthi:Wouldn’t we also need a new proposer boost value? Or is that independent?
01:21:07
Francesco:Replying to "Wouldn’t we also nee..."
independent
01:21:36
Saulius Grigaitis | Grandine:Feels like that oneliner attestations change in Pectra
01:21:44
Barnabas:whats the impl time of
epbs then lower slot time
vs
lower slot time then epbs?
01:22:08
Dustin:Other general point, it's not just "shorter" slot time, it's variable slot time. Doubling the slot time would be similarly difficult
01:22:17
Francesco:Replying to "Feels like that onel..."
Well I don’t think anyone is saying this is a one liner 😄
01:22:57
Francesco:Replying to "Other general point,..."
Slot-Time-Only-Fork
01:23:06
Saulius Grigaitis | Grandine:Replying to "Feels like that onel…"
No one calling it one liner because we has such small change in the last hardfork :D
01:24:00
Sophia Gold:If we can do both delayed execution and 6s slot times in glamsterdam, is ePBS even necessary?
01:24:48
Barnabé Monnot:why isn’t there testing twice though? test restructure, test shorter slots, vs test shorter slots, test restructure? not super obvious to me but maybe missing sth
01:25:18
Potuz:Replying to "If we can do both de..."
ePBS is delayed execution
01:25:20
Barnabas:is epbs + 6 slot slot time in glamsterdam really fully out of the picture?
01:25:30
ethDreamer (Mark):Replying to "why isn’t there test..."
There are several deadlines in a slot - attestation deadline - proposal - aggregation
01:25:31
Barnabas:that way we have one slot restructuring with 6s slot time in mind
01:25:53
Potuz:Replying to "is epbs + 6 slot slo..."
Hell yes
01:25:53
ethDreamer (Mark):Replying to "why isn’t there test..."
We will need pandaops to measure each of these
01:25:54
Sophia Gold:Replying to "If we can do both ..."
We are also debating doing EL-only delayed execution in glamsterdam
01:25:56
Barnabé Monnot:Replying to "is epbs + 6 slot slo..."
i would become a bigger ePBS bull than potuz if it was true! but i don’t think it is 🙁
01:26:07
Francesco:Replying to "is epbs + 6 slot slo..."
Imo if we decided that we really want shorter slot times, we should probably do that + delayed execution on the EL, rather than create a monster feature on the CL
01:26:09
ethDreamer (Mark):Replying to "why isn’t there test..."
If we do restructuring after you measure them, we will change the physics of the slot
01:26:13
ethDreamer (Mark):Replying to "why isn’t there test..."
Forcing you to measure again
01:26:17
Josh Davis:Great job Ansgar!
01:26:29
Parithosh Jayanthi:Great job 😄