stokes:Okay, thanks.
Transcript
stokes:Hello, everyone.
stokes:This is Acdc, 1, 55. The agenda is here in the chat.
stokes:It's issue 1434 on the Pm repo.
stokes:So today we have a few things to switch on for Petra.
stokes:a number of things for Fussaka.
stokes:And yeah, let's just go ahead and get started.
stokes:So with Petra, I'm not sure if there's any testnet updates worth covering.
stokes:As we all know, Mainnet is coming up may 7.th
stokes:And yeah, we had said previously, we would aim for client releases for Petro magnet next week.
stokes:the 21st of April blog post a few days after. That.
stokes:Is, everyone feeling good about this.
stokes:Any issues client teams want to bring up with releases? Or do we all feel like we can make that in time?
stokes:Okay, I'll assume everyone's ready, because no one's chiming in otherwise. Oh, yeah, Mario.
Mario Vega:Yeah, maybe if if that was a question for Cl depths only. But I can give an update from testing and what we were doing on the El side. Basically, we've been writing a lot of new tests and just reviewing tests. But everything looks good so far, what we've been doing is that everything that we write or think about? We just run it against all clients, and if we find something we report it. But so far, it's looking good. And we are more confident that
Mario Vega:than previous weeks about the coverage. So yeah, just wanted to chime in to say that.
stokes:Cool thanks, one quick reminder.
stokes:So we had tried to put in to place a little organization
stokes:for the main net fork. Just in the event, we need any sort of instant response.
stokes:So there's this document here that I linked again on the Pm repo.
stokes:And essentially, it's just having point, people from each client team. Just so in the event, we need to get in touch with someone we know who that is.
stokes:It would be great if you could add some contacts
stokes:in the next few days on this document, just as a Pr.
stokes:and yeah, so take a look at that.
stokes:Otherwise any other pector stuff that we want to get into at the moment.
stokes:I think people generally feel good about it
stokes:and are making progress with releases. So okay.
stokes:If there are no other pector things, then let's turn to Fusaka.
stokes:So with Usaka to kick us off. We have purdos with Devnet 6.
stokes:Devnet 6 is live.
stokes:Maybe Perry or someone would like to give an update just on how that's going.
Barnabas Busa:Yeah, previous agnostics have launched approximately a week ago. And
Barnabas Busa:we seem to be having some problems now, just like started a few epochs ago. It's
Barnabas Busa:basically a few clients are having some issues, especially Nimbus, to have issues. But they said that the Esi also seems to be struggling. So
Barnabas Busa:I haven't had too much time this week to that deep into it.
Barnabas Busa:but maybe some of the client teams can give an update.
stokes:Anyone have anything to share.
Barnabas Busa:I know that in, for example, for us, there was some block processing time issues.
Barnabas Busa:This is for peerless. Yeah.
stokes:Yeah.
stokes:Okay, was this related to this all proof computation.
Roman:Not really it it just for unknown reasons. The block processing time jump
Roman:sometimes even up to 40 seconds.
Roman:Unclear. Why? Because none of the changes happened in in the live sync, so I expect their resource, exhaustion.
stokes:Okay?
stokes:So if you look at the spec, there's a few open prs mainly around Apis.
stokes:I don't know if there's any open questions to discuss on these at the moment.
stokes:I know we touched on them, some on the breakout this week.
saulius:There's check.
stokes:Okay?
stokes:If not, then I assume everyone's busy with Petra. Which soon people will be focused on pure dos.
stokes:And yeah, otherwise we'll focus on the open Prs and keep working towards Devnet. 6.
stokes:One thing that did come up was this Bpo eip.
stokes:and it proposes a configuration so that we can say.
stokes:for example, at this epoch the ball parameter should look like this.
stokes:and there was a question of exactly how this configuration looks.
stokes:There was some conversation on discord. There's a few different suggestions.
stokes:We touched on this during the breakout this week, and I thought we had agreed to essentially have a list of objects or records and Yaml, at least on the Cl. Side.
stokes:but did want to bring this up. Just so we can finalize the decision today.
stokes:Did anyone have any issues with what we settled? Yeah, Gabe has a link here in or example here in the chat.
stokes:So you would have the key. And then, yeah, just this list of the relevant data.
stokes:Anyone have any problems with this?
stokes:I think one thing in particular is like Yaml support per client. Just in the event that
stokes:there's issues parsing this. For some reason everyone feel good about this.
Barnabas Busa:There's also some discussion about potentially having this in a separate file.
Barnabas Busa:I'm not sure what was the decision about that? Or do we just want to include this in the config.
Justin Traglia:I would just like to config or included in the config not a separate file I was, I take that suggestion back.
Barnabas Busa:Okay. So there was another discussion about how we could. How how could the user override these
Barnabas Busa:in case of an emergency override needing to happen because we're writing a list element seems like a weird
Barnabas Busa:way to do it.
stokes:Yeah, I would imagine. Well, yeah, I guess if you wanted to, you could just edit it yourself.
stokes:But I would imagine then clients would just ship with new configs, so you would pull some new release.
stokes:You could even just imagine providing the configuration and replacing just that.
Parithosh Jayanthi:I guess the question there is, if we expect a Ppo to be going badly and we want to emergency cancel it. Would we do so with the new client release? Or would we do so with the flag? I guess if it's with a flag, then we're talking about an override approach. And if it's with a new release, then yeah, it's a new config, and it doesn't really matter. Then.
stokes:Do go ahead.
stokes:I'm not.
stokes:Answer.
Dustin:I want to question the premise. I don't want to spend too much time on this, because I know I've done this a bit in discord. The emergency release thing is not going to happen. I'm I'm going to stay that more or less on the record, I think, not as a prescriptive thing, but as a descriptive thing.
Dustin:the the coordinate. We couldn't get this coordinated for Holeski in time. A bunch of people on a single telegram group on a timescale of minutes, and if you put the time scales involved here, it's a lot of things that go wrong go wrong on the scale of minutes to hours, and then you go from there to what weeks, days, weeks, and at that point that's just not
Dustin:that coordination can't happen. I'm sorry. Please stop. I'm sorry. I'll rephrase. I think that, allowing this
Dustin:fantasy again, I will use that word very deliberately of of an emergency release to guide the design of this in ways that compromise the design in general is, is misguided.
stokes:Do you have an alternative that you would prefer.
Dustin:Well, what it means is that
Dustin:to the extent that including it in this, in the say, a pre-existing configuration, if the only issue there was that it doesn't allow for an emergency override to me. That's just like a non issue.
Dustin:So it doesn't really create another alternative as much as as it eliminates one of the putative reasons for preferring a separate file.
stokes:Yeah, I mean, the separate file bit is kind of a detail. It sounds like you're questioning
stokes:the whole Bpo idea itself.
Dustin:Well, that, too.
Dustin:I've started taking that a bit as a fait accompli at this point I'll be honest. But yeah, I'm not. I'm not particularly convinced about Bpos in this context, either. That's true.
Parithosh Jayanthi:Maybe one more clarifying parameter. I'm not expecting Bpo values to be chosen such that a past Bpo has failed, and we need to schedule a new one to reduce the blob count. But rather, let's say we go from 6 blobs to 9 blobs, and we see a degradation of
Parithosh Jayanthi:5%. And this is a maximum number we had expected, and we have another Bpo for scheduled for about 2 months from now that we have roughly some amount of time to cancel, said future Bpo. So this can be achieved with conflicts being shipped at different times, and you have plenty of time to react because any Bpo section chosen any value chosen needs to allow for enough
Parithosh Jayanthi:time to react as well as be fine grained enough to allow for monitoring to judge the next how the next Bpo. Could go.
Parithosh Jayanthi:So
Parithosh Jayanthi:that being said, Would you still oppose that being declared as an emergency? Because, yes, it is an emergency as in, we need to delay the future fork. But no, it isn't an emergency that you need to make a release today.
Parithosh Jayanthi:It's about cancelling a future fork.
Dustin:No, I would not categorize that an emergency. If if it's in the timeline of when releases are feasible to coordinate, then it's not an emergency by at least a definition. I would see.
Parithosh Jayanthi:Okay? So I would rephrase the earlier point. As this is not an emergency, but having the ability to either override or ship a new config. It sounds like the preference would be to just ship a new config, and we choose Bpo values such that we can always cancel the future one with ample warning.
Dustin:Give. Given everything that would be something I can live with.
stokes:Okay.
stokes:So circling back to this configuration, are we good with this?
stokes:It sounds like, yeah, this structure here, and the standard config that we all have.
stokes:In the event we need to change it. There would just be a new configuration that a user of a client would get in some way
stokes:do we feel like we need to also have like a command line override.
stokes:I mean that to me would be more this emergency situation. But
stokes:it's like another code path to test. And yeah, it it would be tricky to coordinate
stokes:Henrico.
Enrico Del Fante (tbenr):Generally okay, is. The only thing that you want to
Enrico Del Fante (tbenr):point out is that adding that in the main configuration
Enrico Del Fante (tbenr):there is a slightly impact on the on the begin. Api spec endpoint that returns
Enrico Del Fante (tbenr):all the configuration. And we have this structured array. Then we we need to make sure that we render in Jazzon this Bpo schedule, and we don't break any Vc.
Enrico Del Fante (tbenr):That because Vc. Essentially is not.
Enrico Del Fante (tbenr):it's not interested in this information, or for some reason it may may not expect the
Enrico Del Fante (tbenr):edge as an object in the response, as a nested schedule. So
Enrico Del Fante (tbenr):yeah, we need to make sure that we don't break anything.
stokes:Yep, that makes sense.
Barnabas Busa:Just translate to Jason, anyway. So I don't see a problem here.
Enrico Del Fante (tbenr):Yeah, I mean on on the Vc side,
Enrico Del Fante (tbenr):can talk about only only tech. I don't think there is any problem, but any any tooling that consumes
Enrico Del Fante (tbenr):that endpoint. I don't know how is designed and what are the assumptions there, so.
Barnabas Busa:Well, I mean, if we make a decision today about the structure, then
Barnabas Busa:it should give them plenty of time to deal with this later.
stokes:Yeah. And I mean, this is something that will up here in testing.
stokes:I guess, like one issue is, if
stokes:you know, some implementation treats users like unexpected keys and causes an error or something. But
stokes:I I think we'll be okay.
stokes:Cool. So we'll go with this format that gave player in the chat.
stokes:We will put that in the config. Yaml.
stokes:Yeah, Mark, we are.
ethDreamer (Mark):Okay.
stokes:And no no cli, for now.
ethDreamer (Mark):That is currently what is in the IP, or at least like very closely approximating it. The
ethDreamer (Mark):tricky thing is just like the config file is technically a yaml file, but we have never had anything that was like a nested array or anything like that. But that is valid. Yaml
ethDreamer (Mark):But client teams should watch out for that. I I do think it's worth doing it that way, because this may not be the only time that the consensus side has to specify a sort of array like object in the config. And the El side already does it regularly. So if we do have problems with that. It's it's worth fixing.
stokes:Yeah. And again, I think it will.
stokes:I mean, this sort of thing will come up immediately in testing. So we should know
stokes:Justin. Now, should we? Backfill? Didn't have an Electra limits? We need to do Electra, for sure.
stokes:You mean like, include those in the Bpo schedule.
Justin Traglia:And the blob schedule. Yeah.
stokes:Why would we need to do that?
Justin Traglia:So we don't need Dinet. But we do need Electra.
Justin Traglia:I believe. I mean, like, if we just want to use a like a get blob. I get
Justin Traglia:Max Pops per block limit function like it'll need the
Justin Traglia:electro blobs on it which we're using. And truly, at the beginning.
stokes:Yeah.
Justin Traglia:And.
stokes:Yeah, I was thinking about this is, it would just go live after Socca. So Electra would be in place and then slide up for Sokka. And
stokes:sure maybe the there's like the same data in this in this list. But.
Justin Traglia:To be clear. I'm not suggesting that we change how like Alexa works.
Justin Traglia:I'll explain it later.
stokes:Okay.
Barnabas Busa:Regarding testing it would
Barnabas Busa:maybe be a bit problematic then, because we could assume that we're starting with the app, or we can assume that we start from Electra. So then how would you specify that we are starting from the app, or we starting from Electra? If
Barnabas Busa:we just say next blobs per block is whatever.
Barnabas Busa:So I can see that feel.
Barnabas Busa:Then we might need to backfill all the way.
stokes:Because the current shared us. Devnets are on top of Deneb and not Electra.
Barnabas Busa:No, no, they are on top of Elektra.
Barnabas Busa:That like what's gonna be the 1st one, and then it's gonna be epoch 0 and the specific Xbox per block
Barnabas Busa:that we we might have more Bpo schedule in in the future.
Barnabas Busa:And we might have
Barnabas Busa:flu at epoch 0 eventually. And we're gonna have, whatever the next star will be at epoch 0. And then we can have a mismatch of mixed flops per block
Barnabas Busa:scheduling scheme.
stokes:Why would there be a mismatch that would sound like in configuration? Error
stokes:like it should be fine. Just have like, yeah. Epoch. 0 is like the fuller set, and then you just go from there.
Justin Traglia:A slightly different question. Are we going to use the blob schedule for, like future hard forks? It might be what Barnabas is asking
Justin Traglia:so like, for I don't know if we decide to raise the
Justin Traglia:up on that in the future. After Bpo Forks.
Barnabas Busa:Yeah, like, do we want to touch anything else ever? Or is it only gonna be the Max blobs per block
Barnabas Busa:at that specific epoch.
stokes:This should be fine for Fusaka, and
stokes:it could change in the future. I don't really see a reason why at the moment, but it could.
stokes:Okay, cool. I think that's sorted.
stokes:And that does kind of tie into the next point.
stokes:So we have parados.net 6, and
stokes:we should be looking towards Fusaka Devnet 0,
stokes:especially as Pector goes live. That will be the next devnet to focus on.
stokes:We talked about this, some on the breakout this week, and it sounds like there's agreement for for socket of net 0 just on the cl side
stokes:to be pure dust. Mnet 6, and then also go ahead and include the Bpo eip.
stokes:So that would, you know, imply that's implemented and working. And we do have some like initial configuration and data for how we want the socket 0 to look like.
stokes:I guess there's a few things here.
stokes:I guess one, then, is like, Do we want to move this eip to Sfi.
stokes:or do we want to handle that later?
stokes:It's Eip 7, 8, 9, 2.
stokes:I don't have a link handy, but it's there.
stokes:and yeah, this is maybe administrative at this point. But it sounds like we are going ahead and scheduling this Bpo eip for inclusion.
stokes:Should we just go ahead and do that formally?
stokes:Okay, Armas has a question no reason to do for sake of 0 if we don't have Eos?
stokes:Yeah, the intent is to have some version of Uf ready for for soccer. Devnet 0.
stokes:I don't know if we want to touch on that today.
stokes:but I think we should aim for this to have 0 again with pure dos. Devnet 6 and vpo
stokes:we had suggested on the breakout this week to aim for somewhere around May 20th
stokes:for for socket dot 0.
stokes:Does that timeline sound reasonable to everyone?
Barnabas Busa:I think the timeline is a bit more questionable at this point, and if we don't like, if we don't include the latest version of it, then I don't think we should do, and we should just do Bpo with.
Barnabas Busa:because there's no there's no reason to have an old version of the OS.
Barnabas Busa:Pushed on top of this this branch.
stokes:Yeah.
stokes:I hear that I would think we try to get everything ready I don't know if Dan or any of persons here today. But this is something I guess we can discuss next week, if not today.
stokes:And I do think we should push for this it'd be good to have a
stokes:even if not completely stable, but a devnet 0 up as soon as possible.
stokes:yeah. And sure, you know, if it looks like Uf isn't ready. Then we'll probably do what you're suggesting. Suggesting Barnabas.
stokes:Yeah, Perry says, as far as he knows, the timelines should align.
stokes:and no one seems to have any issues with this May 20th approximate date. So I think we should have that in the back of our minds.
stokes:Okay?
stokes:And to be clear, it looks like there are enough comments in the chat to go ahead and sify
stokes:Eip 7, 8, 9, 2. So I can go ahead and make that change later today to the Meta eip.
stokes:And that tease us up to the next agenda item, which is the Cfi set for Fusaka.
stokes:So to recap we currently have pure dos sfied, meaning it is shipping
stokes:we just moved the Bpo eip to Sfi from Cfi, meaning the Bpo eip is shipping
stokes:from there. There are a number of Cfi eips to discuss.
stokes:We had touched on this last Acdc and yeah, essentially, just given
stokes:the timing of different eips when they are proposed, and essentially having the deadline for Fussaka Cfi.
stokes:we wanted to revisit those today.
stokes:so we should go ahead and make a final Cfi call perfect soccer today.
stokes:And again from last call and looking at the Meta eip.
stokes:the only real eip that stuck out today to discuss for Cfi. Is this eip? 7, 9, 1, 7. This is the proposal. Look ahead, Eip.
stokes:There were a number of other ones that we essentially lean towards Dfi for Fusaka
stokes:again, acknowledging that we essentially want to exclusively focus on pure dos and eof for this work.
stokes:So given that context, let's touch on 7, 9, 1, 7.
stokes:Would we like to Cfi it, or otherwise move to Dfi. On this call
stokes:Asgar says, Dfi. 7, 9, 1, 7, and Dfi the others?
stokes:Okay, so we don't know.
Dmitry Gusakov:From here back. Yeah. So I just want to make a short note regarding 7, 6, 8, 8, yes, is usually so, or together with the mixed bytes team we are currently working on a like a detailed research on the actual effects and the actual impact of implementing this eap
Dmitry Gusakov:the research is aimed at understanding, who is currently using for 7, 8, 8, which is
Dmitry Gusakov:beacon root on execution layer, which is directly connected to 7, 7, 6, 8, 8,
Dmitry Gusakov:and the preliminary outcome is that currently Eigenlayer, Lido, and one more protocol which I cannot remember by heart is actively using this eap. And there is, like around 10 or more protocols who are currently working on
Dmitry Gusakov:implementing for 7, 8, 8
Dmitry Gusakov:into their protocols. And again, I want to point out that without 7, 7, 6, 8, 8,
Dmitry Gusakov:they all will have to do. Some sort of a maintenance should become State change which
Dmitry Gusakov:it most likely would in Fasaka.
Dmitry Gusakov:So just want to point out again that by including 7, 6, 8, 8 into Fusaka, we will save a lot of time and effort on the
Dmitry Gusakov:up layer for the app layer developers. And again, the the actual research, unfortunately, is not ready by today, but it will be published, I believe, this week.
stokes:Okay, thank you.
stokes:Let's just circle back to that.
stokes:because I do want to make a decision on 7, 9, 1 7, is anyone
stokes:in favor or against Cfi?
stokes:I would like to hear from clients. Frederick.
Radek:Hi, so yeah, I already wrote on discord some time ago that I am weekly against
Radek:because of the, you know, not because the the vip itself is technically, you know, something's wrong with it.
Radek:But because of the
Radek:you know what we agree agreed on of how we are going to, you know, work from now on in terms of scheduling forks and including stuff. And I'm looking right now at teams diagram where there was a minus one. And N and N. Plus one, I can share it with you. It's in the all core magicians. And if you look at that, if you look at the 1st diagram from this post
Radek:for fork, and we can propose eips between testnet and mainnet releases for the previous fork. So in that terms, it's perfectly fine, in my opinion, to include the cip, but I think we also agreed that we shouldn't include eips that are like not like
Radek:change something in the consensus if we don't have testnets that have been running with many clients, and they are working, and for the cip we had 0.
Radek:And so that's why I am slightly against including the cip.
stokes:Right?
stokes:Yeah.
stokes:So I hear you with the point that.
stokes:yeah, like, what we should be very careful to do is not include a bunch of vips into a fork
stokes:without due diligence. We saw with Petra that that was problematic. So I don't think anyone wants to do that.
stokes:I think at the same time, the way that we now have the setup of Pfi to Cfi. To Sfi it seems like Cfi. Is this like conditional approval that it's worth looking at in more depth, and that's where. Then we do the due diligence
stokes:and then maybe just like round this out, like we wouldn't put this into. Say, if we saw nets until everything else has essentially been proved out to be stable, right? So
stokes:we would still focus on pure dos, and eof
stokes:only when that's the case, would we then circle around to the Cfi side?
stokes:And I'm not really making a general claim about the cip in particular. But that's the high level process. So
stokes:I think it's helpful context.
stokes:And yeah, okay, I think, taking the comments on the call and in the chats were like net neutral.
stokes:There's like a number of weekly in favor weekly against.
sean:So the lighthouse team were weakly in favor. I think it does introduce a feel to the Beacon State, where, like we wouldn't have any beacon state changes otherwise. So that is like a reason not to do it, but
sean:weekly and fear prototype.
ethDreamer (Mark):Not to do it for other teams. I mean, we already have the infrastructure. But other teams may not necessarily have
ethDreamer (Mark):put in the boilerplate code to have changes to the Beacon state. So, and if that's like a huge
ethDreamer (Mark):amount of undertaking that would delay the fork, then we can understand that.
Barnabas Busa:How hard is it to implement this vip?
Barnabas Busa:Because if it's really just done under one day, and it could be included in the next subnet without any problem from every single cld.
Barnabas Busa:then it wouldn't like delay the fork, but if it takes like weeks and weeks of effort, then it should be not included.
Tim Beiko:And I don't think I would push back against including it in the next devnet until we have tiered as an Eof, even if it's a 1 day thing like, I think this is how we got screwed in Petra. We should make sure we have a stable thing that works and then decide if we want to add more. So obviously, how long it takes makes a difference. But I I think once we have
Tim Beiko:academic 0, 0, we can look at the Cfi vips and decide, okay, which ones make sense to add the fuse. Academic one. But
Tim Beiko:yeah, let's let's not include it already.
Barnabas Busa:I'm not saying to include it, I'm saying to keep it as Cfi, just not yeah. Fire it.
Lin Oshitani | Nethermind:Yeah, I'm interested in what like the Cfi thing they consider needs to be included. Because.
Lin Oshitani | Nethermind:like, I completely agree that pure desk is top priority like without that.
Lin Oshitani | Nethermind:like all roll ups based or not, based like on skill.
Lin Oshitani | Nethermind:but like being considering as in like, as long as it doesn't interfere or like
Lin Oshitani | Nethermind:with pure desk scheduling, we can consider it for inclusion. I think there'll be a good position, and I'm happy if there
Lin Oshitani | Nethermind:and yes, it's gonna be very like useful for be confirmations.
Lin Oshitani | Nethermind:It's a relatively small team. So yeah, introduce student people are.
Lin Oshitani | Nethermind:yeah, opposed to even considering it.
stokes:Okay, I think, given the input and the fact that this is only Cfi and not Sfi.
stokes:it seems like it's okay to move ahead with Cfi for this today.
stokes:Is that okay? With everyone.
Potuz:Elect.
stokes:Yeah.
Potuz:Oh, I'm not sure I I can't raise my hand. I'm driving middle of nowhere.
Potuz:so I just want to mention. I'm not sure because this was cutting off. But including this and testing this would be quite a big change in that. It is the only thing that changes the Beacon state when there was another eip that was mentioned, as if this was going to be something surely to happen in Fuzaka that we would change the Beacon state, but so far out of the eips that we're considering. Nothing touches the Beacon State.
Potuz:And I think the crucial question we should be asking ourselves now is, do we really want to change that structure just because of the cip?
Potuz:Because of this feature? Do we want to change the beacon state.
Amir:Thankfully.
Amir:Tell them poet is.
ethDreamer (Mark):I suppose the answer to that question would depend on where other clients are
ethDreamer (Mark):in, in how prepared they are to change the beacon state.
stokes:Right. That sounds like it might be easier for some clients than others.
Dmitry Gusakov:Well given, even though we don't have such a process yet.
Dmitry Gusakov:Of consider like of specifying something for the hard fork after the next hard fork, and given the common bipartis, that and many others, that with the current scope of ssified Eaps there will be no changes to Beacon State. If we can agree, say.
Dmitry Gusakov:of sifying this eip for the Glamsterdam
Dmitry Gusakov:that might work. So if we 100% sure that there's no changes to beacon State Infosaka, which means that there's no issue to address, at least in this hard fork, and we can sfi now it for the next hard fork. I think it will solve solve the issue that might pop up should some changes to the State appear in Fusaka.
stokes:Right, and I guess this kind of gets to. I think Ongar was trying to prompt either Justin or Lynn
stokes:like, how bad is it to hold off on the zip or the Procomm's use case.
stokes:because it seems like that was the main use case that the cip would support.
Lin Oshitani | Nethermind:Yeah, I can give some context around the pre confirmation. So like pre confirmations like, without this cip, what would happen is that we would like. What we are discussing right now is basically having the oracle.
Lin Oshitani | Nethermind:Oh, a close to or like trusted oracle solution which would like
Lin Oshitani | Nethermind:make ensure that the lookout is available in the Avm. And there's
Lin Oshitani | Nethermind:which is like it will work.
Lin Oshitani | Nethermind:and we can have reconfirmations. But
Lin Oshitani | Nethermind:yeah, it's kind of a hacky solution, I would say, and awesome.
Lin Oshitani | Nethermind:They're not a you.
Lin Oshitani | Nethermind:And once we have the cip like, we'll have the look ahead completely available in the
Lin Oshitani | Nethermind:Evm. And a stable way which would remove all the need of hacks, and we'll really simplify
Lin Oshitani | Nethermind:the protocol that we have.
stokes:Reddick.
Radek:Yeah. So I actually think I changed my position to slightly in favor. But
Radek:I would just like to state that similarly to the attestation eip in the previous fork, which was supposed to be easy, but turned out to be huge. I don't expect this one to be as big. I
Radek:hope it will actually be as simple as you know, the people who have already implemented it are saying, but what I think we should like agree on is that if
Radek:we start working on it and start having definites for it, and it turns out that it actually is more involved than we initially thought, and you know there's this and that, and you know whatnot, etc. And we see that it's growing and growing. We should make a decision to roll back, and you know, not
Radek:continue, and you know, try to push it and try to to complete everything so that it's ready and just say, Okay, it. It turned out to be more complicated than we thought. Let's move back and schedule it for the for Amsterdam, and not try to push it for Fussaka.
stokes:Yeah, no, I think that makes a lot of sense. And that seems generally the same page that everyone's on.
stokes:Matthew.
Matthew Keil:I definitely want to just verbally. Second, what Tim said, that we don't want to get ourselves into the same situation that we had with jamming things in. And even though this isn't a jam, we don't know the scope. Let's get what's on the current roadmap in. Get the devnets running, and then, if there's still time, we can always add stuff in.
stokes:Right? And so, yeah, I mean, at least, that's how I'm thinking about the use of Cfi here is
stokes:it allows us to make this call later. Obviously, that means that there's like some initial due diligence. And if it
stokes:becomes problematic in the way Radek and others are suggesting, then definitely, it would not be specified.
Matthew Keil:But I think the biggest thing is is to not take away dev velocity from the current development and the current feature set and just keep focus and keep keep scope small so that we're all going in the same direction. And we can make sure that we're gonna get the next work, both quickly and smoothly.
stokes:Yeah, I mean, that's why I like this pattern of basically only having sfi things on devnets only once, we feel good about those. And they're stable. Do we consider other things?
stokes:Okay? So I think, taken all together, then it sounds like there is at least week support for Cfi and the cip. 7, 9, 1, 7. So let's go ahead and do that.
ethDreamer (Mark):I also just wanted to point out, like one of the concerns of this vip was just that it might
ethDreamer (Mark):you know, burden epoch processing a little bit more because you have to calculate all the next epoch proposers
ethDreamer (Mark):at epoch processing time. But I did some measurements with lighthouse, and that doesn't appear to be a concern, even like lighthouse, even the naive implementation. I I hadn't used caches that we have, and the fact that we have Tree States makes the proposal calculation extra slow without those caches.
ethDreamer (Mark):But it was only making epoch processing about 2 to 3% slower. But I'll see with caches, and I think it may not be necessary in other clients that don't need tree States to use caches. So.
stokes:Okay, thanks.
stokes:Yeah. So yeah, maybe just to summarize like week support to Cfi. So we'll go ahead and do that.
stokes:Everyone is saying that essentially, at the 1st sign of any complications, we just essentially deify it for Fusaka.
stokes:So we would not, Sfi. It would not move on to any devnets, and we would move forward.
stokes:Okay, then we did have one other eip to touch on. Dimitri wanted to
stokes:discuss 7, 6, 8, 8. And yeah, I mean, I think it's essentially the same conversation we just had for this eip
stokes:just to be clear. This eip is about the stable containers. And the main thing is, it keeps these generalized indices in the
stokes:proof part of Sse stable. Yeah.
stokes:we had touched on this last Acdc. And again, I think, given like scope considerations. And the fact that we do want to focus on
stokes:paired us pretty exclusively.
stokes:Yeah, essentially, there wasn't that much support to Cfi list.
stokes:We're here. So anyone would anyone like to see if I it's
stokes:or do we think we should not.
Dmitry Gusakov:I mean again rolling back to the previous comment. So if there's no changes to the state.
Dmitry Gusakov:there's no need for this eap.
Dmitry Gusakov:which is great. If the previous one would be included, I would hide the
Dmitry Gusakov:recommend, including, like both of them.
Dmitry Gusakov:So the 7 9 whatever, and this one, if not, then it's like it's fine to
Dmitry Gusakov:to keep it for later.
stokes:Yeah.
stokes:I mean, yeah. So the obvious issue is, we have this like, kitchen sink situation where we're like, okay, we put this one. Then we need this other one, and then you know it. Cascades, which you know, I think everyone is very aligned that we don't want to add a bunch of vips to Visaco.
stokes:Yeah, so
stokes:yeah, just kind of summarizing the chat here. Like, I think, following the previous argumentation, we just had like, it would make sense to Cfi. But I think then it's kind of as I'm saying.
stokes:it starts to feel worse if we have all these things that could potentially go in.
Dmitry Gusakov:So just again, just just one suggestion from my side. If we Cfi like the previous 1, 7, 9 1 7, then we also did. Cfi. 7, 6, 8, 8. If we not, then let's Dfi both of them.
Dmitry Gusakov:and then we are good.
stokes:Okay. So does anyone disagree with this approach that we should see if I, both or neither.
sean:I I disagree. I think we should just see if I the proposed look ahead, and not 7, 6, 8, 8.
sean:I just think it's a simpler change. And I think it's yeah valuable.
Radek:If the proposal look ahead, one has benefits without the other one, then let's include just one.
Radek:If it doesn't have any benefits without the other one.
Radek:Let's not include any of them.
Enrico Del Fante (tbenr):Yeah, as far as I understood.
Enrico Del Fante (tbenr):it, does have benefits on one side, but then creates problem on other sides. So
Enrico Del Fante (tbenr):it's not the same use case.
ethDreamer (Mark):My my understanding is that even if we include 7, 9,
ethDreamer (Mark):when ain't the the proposal? Look at Eip that we're not going to break proofs for the Beacon State, because we're not crossing a power of 2 boundary.
ethDreamer (Mark):and if that's the case, then
ethDreamer (Mark):we don't. There's not like a huge motivation to put
ethDreamer (Mark):7, 6, 8, 8 in this fork, because, no matter what there needs to be, at least one
ethDreamer (Mark):time that the app layer is gonna need to update their proofs
ethDreamer (Mark):when we include stable containers hopefully, exactly one time. My hope is that we can include stable containers
ethDreamer (Mark):when we make a change to the Bea state that breaks proofs so that they only ever have to do this one more time.
ethDreamer (Mark):But right now my understanding is that even if we include
ethDreamer (Mark):7, 9, 1, 7, that we're not going to break the proofs. And so this is going to be the exact same amount of work for the app layer, whether we include 7, 6, 8, 8, or not in this form. Well, actually.
ethDreamer (Mark):there, there they would have to update their proof sooner if we included it in this fork. But
ethDreamer (Mark):either way it needs to be at least once more and hopefully, exactly once more.
stokes:Okay.
stokes:Anyone want to speak strongly to coupling them.
Enrico Del Fante (tbenr):So I if I'm if we are sure that
Enrico Del Fante (tbenr):introducing that doesn't break anything on the proof side makes sense to separate them.
Enrico Del Fante (tbenr):but from from from from technical perspective. As I also said, you wrote, we are kind of
Enrico Del Fante (tbenr):okay to bundle them, because we have already oh.
Enrico Del Fante (tbenr):an implementation of 7, 6, 8, 8. But problem is, I don't know if other clients ever have everything already for 7, 8, 8, 10,
Enrico Del Fante (tbenr):7, 6, 8.
stokes:Yeah.
Enrico Del Fante (tbenr):Maybe delays for other reasons.
Enrico Del Fante (tbenr):Fork.
stokes:Yeah, my understanding is, there's provisional support across various as the implementations. But this is something that
stokes:is like very low layer and touches. Yeah.
stokes:Oh, it only touches Sz code. But
stokes:that's used as like a foundational layer for many things.
stokes:So okay, yeah, Matt.
Matthew Keil:So I think, from a broader ecosystem perspective. And I think this is something that really we should reflect on is
Matthew Keil:we want to get to faster forks. We want to get to more regular forks, and there's nothing that stops us from just getting the small feature set that's nearly ready out now and then in 3 months. We do those 2, you know, if we, if we can get to this fast iteration of forks and really get ourselves into that mindset. All of these eips are much easier to get included.
Matthew Keil:and maybe as a trial, we just get this one out quickly and just keep it limited, and then that might set a precedence going forward.
Dmitry Gusakov:Yeah, that that's a very good comment. But again, what we should keep in mind is that we, if we move to a faster, hard works, and if we do not have stable containers, then each and every fast hard work would require this shitty maintenance, which is a huge pain in the ass. So if we really want to move, to have to fast hard works, we also should think about like not introducing complications and hurdles for
Dmitry Gusakov:applications. So I fully agree that if in this hard work, if Infosaka, there's no changes to be considered, no changes to proofs, it's perfectly fine, then we include stable containers into the next hard fork, and then we can move like at any pace we want, because at least this part will be solved. But if we will not solve this part, and we will just transition to a fast, hard forks, and then, for example, each and every of them, or some of them will change the way. How proofs work
Dmitry Gusakov:it would create like enormous pain for the applications that's also important to keep in mind. So it's not just about being fast on the core side, but it's also thinking about applications and making it.
Dmitry Gusakov:not creating additional complications for them. With this increased speed of hard forks, but in general I'm I'm fully for the increased speed of Hard Fork.
stokes:Frederick.
Radek:Yeah. So if I understand math correctly.
Radek:This this proposal was, you know, we're working on pure das, we're working on some other small eaps. These other eips are ready. We can ship them in maybe 3 months. And
Radek:I wanted to push back a little on that from engineering perspective. Because if we are working on pure das as the main eap, we are slowly merging stuff into our, you know, core code modifying sometimes very core functions and a lot of changes. And then, even if you have these other eips ready, then
Radek:how do we? How do we release our clients? We would have to roll back all the you know. For example, peer does call so it doesn't interfere, and that it breaks nothing or maintain forks for every eip, and then somehow merge them together. It would be a nightmare, in my opinion, so I don't think this is something realistic.
Matthew Keil:That's exactly what I'm saying, though, is like right now, we're so focused on the big 2 like, really, it's pure das and eof on both sides. And anything that gets in the way of that will take away development velocity from us, actually getting those features 100% across the line. And that's that's exactly what I'm talking about. Radek, like. If we stay laser focused and make sure that we're all aligned towards those goals.
Matthew Keil:we can get it done quickly. It might only be a few months before we're ready for the F. Fork, and then it could possibly be a few months for the G. Fork after that, but I think
Matthew Keil:limiting the scope so that we're all moving in alignment towards each one of these forks, I think, is critical in order to be moving, moving the ecosystem forward as whole.
Matthew Keil:It's also more predictable for all the consumers, and I and I also agree with stable containers critical. But again, like, we already have the development velocity of where we're going for now. And you just you just have to choose what's what's the priority.
Radek:Okay. I apologize. I misunderstood you. Sorry.
stokes:Okay.
stokes:So then, following the discussion.
stokes:it sounds like 7, 9, 1, 7 won't impact the proofs. So then we lean towards, not Cfi and 7, 6, 8, 8, because there just will be no change.
stokes:We can handle it in a future fork.
stokes:So then we'd Cfi 7, 9, 1, 7, and yeah, basically, defi everything else sounds good.
stokes:Okay, thank you. Everyone.
stokes:Okay. So then, yeah, the Fusaka Vip set should be sorted.
stokes:And there was one more thing on the agenda. And yeah, I guess. Is there anything else on Fusaka?
stokes:This last point was around the builder Apis and the Med workflow?
stokes:It's something I did want to bring up. But yeah, I guess before that, any other for soccer comments.
stokes:okay, so then, yeah, this last thing.
stokes:this came up when we were working on the builder Apis for Fusaka.
stokes:I believe. I think it was Francis who originally made the Pr, let me just double check.
stokes:Yeah, so essentially, we have the builder Apis, and we are updating them for for Fussaka, where
stokes:the main change was, I think, the cell proofs but either way, that was not the issue the issue was that jimmy, then was looking at this and raised the question, you know what happens as we're thinking about this Api in terms of very high blob counts right? So today, there's like a relatively small number of bobs.
stokes:Even with Fussaka, we could get to like quite a large number.
stokes:And the question, then, is essentially the scalability of this Api.
stokes:So how this has worked since the merge is that
stokes:if I choose to use web boost, I, as a proposer, give my signature to the relay, and I get back the execution payload
stokes:with the Neb, we added the blobs. So then it makes sense to then also add the blobs to this Api as well.
stokes:And now the question is, as we increase the blog count. What happens?
stokes:This is potentially an issue, because it's a synchronous Api
stokes:so you would again, as a proposer, you would call the relay and get back the execution payload and all these blobs. And I think it was something that like.
stokes:say, there's 72 blobs which is potentially a balance for Visaka. I think it was something like 10 MB of data in the response.
stokes:The concern is, you know, if I'm using my boost, I might also be like a relatively under resourced mode. And so now the question is like, is this even valuable, or the right way to think about this?
stokes:And there's a number of things to do here.
stokes:or that could be done. So one of them is a pretty radical change where we just actually have. We don't have this Api at all where there's no response. What this means is that the the relay itself is entirely responsible for gossiping the block and blobs
stokes:on their end.
stokes:We could leave the status quo, where again the relay just returns all the data to the proposer, who then also gossips the data on their end.
stokes:There's a sort of middle ground where you return the payload to the proposer, and then we have some other way to distribute bobs that could be sort of an asynchronous Api with the relay between the proposer.
stokes:Also, someone brought up the point. I get blobs, and you could imagine that you might not even need to get the blobs from the relay
stokes:point being there's a concern about this Api. There's a couple of things to do here. And I wanted to get feedback on different these different ideas.
stokes:Does anyone have any initial response or reaction? Or also questions.
stokes:does anyone feel like we need to change the Api.
stokes:because that was the the original concern that basically, it would be too much data for a proposer to download in time.
Barnabas Busa:It is too much data.
stokes:Okay.
stokes:Parents.
terence:I mean, this is also like an issue today with regarding to time out right, because relay will time out or will apply some delay before returning. The data. And typically client side has this time I thought, time out threshold. So it's a little confusing sometimes when you see, like an error from a relayer saying that
terence:Or seeing some error on the valid client saying that we failed to propose a block because of relayer, didn't return the block on time, and it's a scary log. But if you look at beacon blocks forward, your block is actually proposed. It's actually released by the relay on time and stuff. And this happens today quite frequently, and then it's not nice we should fix it. And I think this is kind of we can probably like kill, like 2 birds with one stone here like this, will also resolve that.
stokes:And to be clear. Your suggestion is just to return. Nothing.
terence:I mean, I don't have a good answer. I need to study this problem more. I think you return something, but not like. But don't rely on proposer to like gossip, the blog kind of if if that makes sense. Yeah, I need to think about this more.
stokes:Okay. Yeah.
terence:I mean, that's.
stokes:That does makes sense. Yeah, okay.
stokes:So I'm at least hearing. We think we should revisit this Api for Fusaka.
stokes:which might be enough for today.
stokes:I've reached out to a number of different builders and relays to get their perspective as well. They're kind of in progress of reviewing this?
stokes:Yeah.
stokes:Anyone feel like we should leave it alone.
stokes:Okay, just going off the chat here. It seems like people generally think we should do something.
stokes:There's a question. Let's see, would this impact the trust assumptions based by pure dos?
stokes:If we have a handful of relays?
stokes:Yeah, I mean, the relays would be responsible for getting the data out as well right? Because otherwise builders wouldn't use them.
stokes:So short answer is, No.
stokes:okay. That was helpful. I'll probably well, I will keep getting input from different relays and builders.
stokes:And yeah, that will end up.
stokes:probably with some kind of diff to this pr.
stokes:and we can move forward from there.
stokes:Let's see, I believe that was everything on the agenda. So yeah.
stokes:any closing comments. Otherwise we'll wrap up for the day.
stokes:Okay, then, thank you, everyone. I'll see you next time.
Mario Vega:By, the.
Ansgar Dietrichs:Thank you. Goodbye.
Dankrad Feist:I know.
Chat Logs
00:00:19
stokes:https://github.com/ethereum/pm/issues/1434
00:02:26
stokes:https://github.com/ethereum/pm/blob/master/Pectra/pectra-mainnet-plan.md#client-team-coordinators
00:02:42
Nicolas Consigny:Replying to "gm gm gm"
Taking time away from yappers to listen to real work 🤝
00:04:36
Parithosh Jayanthi:Are we on pectra or peerdas? Because that update was for peerdas-devnet-6
00:04:47
Roman:Still debugging
00:05:13
Justin Florentine (Besu):where in discord is this issue being worked?
00:05:23
Parithosh Jayanthi:Replying to "where in discord is ..."
Peerdas-testing channel
00:05:23
Barnabas Busa:Replying to "where in discord is ..."
peerdas-testing
00:06:00
Justin Florentine (Besu):Replying to "where in discord is ..."
🙏
00:06:31
Barnabas Busa:Replying to "where in discord is ..."
wen besu ready?
00:06:48
Gabe:Like this:
# BLOBS BPO
BLOB_SCHEDULE:
- EPOCH: 348618
MAX_BLOBS_PER_BLOCK: 48
- EPOCH: 355368
MAX_BLOBS_PER_BLOCK: 56
00:07:14
Parithosh Jayanthi:Options: https://discord.com/channels/595666850260713488/1252403418941624532/1362353806620495964
00:07:32
Marius:You're only asking for cl, right?
00:07:42
stokes:If we do EL we should timebox
00:07:46
Parithosh Jayanthi:Replying to "You're only asking f..."
First CL decision, then EL decision I’d guess
00:08:20
Marius:Replying to "If we do EL we shoul..."
The real yappers of the execution layer
00:08:42
Dustin:this emergency thing is not going to be likely feasible
00:08:58
Fredrik:Flag to me is an emergency solution (but that will also be hard to coordinate), while config is the long term solution
00:09:13
nflaig:+1 to what Dustin is saying
00:10:01
kasey:Relying on new binary releases does add a point of failure to the intervention. All client teams need to be available and able to quickly release binaries.
00:10:09
pk910:different configs would lead to a fork, no?
so even a emergengy revert needs to be coordinated. It's not like the gaslimit which is a result of voting from all participants
00:10:50
Preston Van Loon:fwiw - Mainnet typically has much higher SLAs since folks have real money at risk so reaction time is expected to be better.
00:10:52
Justin Florentine (Besu):ah, so heroic action is not a premise we can rely on or design from
00:11:20
Dustin:Replying to "ah, so heroic acti..."
precisely
00:13:19
kasey:Isn’t the flag concept an implementation detail anyway? We should certainly ship new configs ASAP when we change the BPO in any case.
00:13:32
Barnabas Busa:we don’t need cli override imo
00:13:34
ethDreamer (Mark):CLI is difficult to even specify
00:13:35
Parithosh Jayanthi:Feels easier to avoid the cli option
00:13:41
stokes:ok
00:13:48
terence:+1, no CLI per spec
00:13:57
Justin Florentine (Besu):Replying to "ah, so heroic action..."
@Dustin you alluded to this already being discussed in Discord, was that in the peerdas channels?
00:14:46
kasey:Replying to "ah, so heroic action..."
thread: https://discord.com/channels/595666850260713488/1252403418941624532/1360292816235925605
00:15:38
ethDreamer (Mark):Are we discussing the format of the config?
00:15:42
ethDreamer (Mark):Like this:
# BLOBS BPO
BLOB_SCHEDULE:
- EPOCH: 348618
MAX_BLOBS_PER_BLOCK: 48
- EPOCH: 355368
MAX_BLOBS_PER_BLOCK: 5
00:16:39
Justin Traglia:Should we back-fill deneb & electra limits? We’ll need to do electra for sure, but not sure if we should do deneb.
00:17:37
kasey:I think it would be alright to do that, would streamline implementation.
00:18:17
Dustin:For Nimbus, it wouldn't really help do backfill as far as I can tell, Nimbus is already fork-driven in a way, so for deneb/electra it just does none of this
00:18:38
Justin Florentine (Besu):community request: I need an agent that can look at an ACD agenda, and then collect and summarize discussions on each point from discord, eth-magicians, public telegrams, etc
00:19:20
Josh Davis:Replying to "community request: I..."
I might be working on something like this ;)
00:19:53
Justin Florentine (Besu):Replying to "community request: I..."
omg pls. i'm 20 mins into this call and already had to expose my ignorance twice. and I haven't exactly been slacking off this week
00:20:15
ethDreamer (Mark):If we did change things in the future
00:20:25
ethDreamer (Mark):It would be something besides `BLOB_SCHEDULE`
00:20:32
Nicolas Consigny:Replying to "community request: I..."
actually starting with this call every ACD summary will be posted to discourse
00:20:47
Nicolas Consigny:Replying to "community request: I..."
adding discord convo should only be a few more lines @Justin Florentine (Besu)
00:21:15
Enrico Del Fante (tbenr):Does anyone have the link to the BPO eip?
00:21:19
Justin Florentine (Besu):Replying to "community request: I..."
sick, thank you. now just to get the devs to converse in fewer places
00:21:27
stokes:EIP-7892
00:21:32
Barnabas Busa:no reason to be fusaka devnet 0 if we don’t have EOF.
We could just do BPO on peerdas devnet 7
00:21:35
Enrico Del Fante (tbenr):Thanks!
00:21:35
ethDreamer (Mark):https://eips.ethereum.org/EIPS/eip-7892
00:21:55
Nicolas Consigny:Replying to "community request: I..."
https://github.com/ethereum/pm/blob/master/.github/ACDbot/README.md
00:21:56
ethDreamer (Mark):👍
00:22:00
terence:ship it
00:22:00
Enrico Del Fante (tbenr):go
00:22:14
Parithosh Jayanthi:Have all clients had a look through their codebase and can confirm there aren’t any big foot guns with BPO?
00:23:31
Parithosh Jayanthi:Afaik eof-devnet-1 should be ready by may 20th
00:23:59
Parithosh Jayanthi:And the eof people are aware of the timelines
00:24:11
Ben Adams:can do with eof-devnet-0 now; if that helps?
00:24:32
ethDreamer (Mark):🎉
00:24:48
Parithosh Jayanthi:Replying to "can do with eof-devn..."
Not really, we’d like to merge the peerdas-eof worlds with eof-devnet-1, and do any changes on both side after that point
00:25:00
Parithosh Jayanthi:Replying to "can do with eof-devn..."
But yeah, if the timeline sounds wrong then we would ofc re-evaluate
00:25:59
Ansgar Dietrichs:I’d be for accepting EIP-7917, and for rejecting the others
00:26:15
Barnabas Busa:https://github.com/ethereum/EIPs/blob/master/EIPS/eip-7917.md
00:26:25
Gajinder Singh:Replying to "I’d be for accepting..."
+1
00:26:46
Ansgar Dietrichs:but weak on support for EIP-7917 (seems quite useful, but also: small fork!), happy to reject it if otherwise little support
00:28:23
Gajinder Singh:7688 is important as well imo
00:28:28
Justin Florentine (Besu):Replying to "I’d be for accepting..."
am i correct in assuming it facilitates early execution, which facilitates sealed tx and encrypted mempool designs?
00:29:16
Justin Florentine (Besu):Replying to "I’d be for accepting..."
sorry - delayed execution
00:29:22
Radek:https://ethereum-magicians.org/t/reconfiguring-allcoredevs/23370
00:29:29
ethDreamer (Mark):Lighthouse is weakly in favor of 7917 so long as clients have an easy time of implementing it - it was very easy in lighthouse - enough to not delay the fork at all
00:30:05
Phil Ngo:+1 Radek. I think 7688 is important and so is 7917, but we’re opening doors now that resemble Pectra where things get added and we have to question why X over Y
00:30:09
ethDreamer (Mark):Replying to "7688 is important as..."
There are no consensus data structure changes in this fork
00:30:27
Parithosh Jayanthi:Isn’t CFI when we include it in a devnet though? SFI is what goes in a fork
00:30:28
Tim Beiko:At most, we should CFI, but not SFI anything else until we’ve got the devnets done 😄
00:30:45
Gajinder Singh:we shouldn't shy away from CFI
00:30:48
nflaig:Replying to "7688 is important as..."
if EIP-7917 gets in there is
00:31:00
Justin Florentine (Besu):starting to think maybe we just lack discipline
00:31:13
ethDreamer (Mark):Replying to "7688 is important as..."
It wouldn’t break proofs though even if it is included
00:31:14
Tim Beiko:Replying to "Isn’t CFI when we in..."
CFI → we plan to include it in a devnet
SFI → next devnet
We should expect that not all CFI’d EIPs get eventually SFI'd
00:31:20
ethDreamer (Mark):Replying to "7688 is important as..."
That was my understanding
00:32:12
Ansgar Dietrichs:looks like justin drake is on the call to maybe give some context on how much of a difference it would make for this to be in fusaka vs glamsterdam?
00:32:24
stokes:Replying to "looks like justin dr..."
@Justin Drake ?
00:33:01
terence:for prysm
2 days to implement, 1 day to test, a few weeks on a devote / testnet etc etc
00:33:11
terence:potuz already evaluated the pr
00:33:43
Justin Drake:Replying to "looks like justin dr..."
It allows preconf teams to skip hacky solutions for the lookahead and ship preconfs months earlier.
00:34:08
Parithosh Jayanthi:Replying to "looks like justin dr..."
Are there other blockers for preconfs? Or is this the biggest blocker right now?
00:34:22
Trent:Replying to "At most, we should C..."
Bumping this
00:34:50
Dmitry Gusakov:Yep
00:34:52
ethDreamer (Mark):👍
00:35:06
Justin Drake:Replying to "looks like justin dr..."
On L1 it’s the only blocker.
00:35:35
NC:If we CFI 7917, then we can consider CFI 7688, since the original argument of not CFI 7688 is that there is no consensus data structure change in fusaka (which there will be in 7917).
00:35:58
Gajinder Singh:why is beacon state so sacrosanct ?
00:36:12
Ansgar Dietrichs:I do think “better L2 UX” should be a general top priority right now. I am not familiar enough with preconfs or this EIP to judge how much of an impact the EIP would have on that
00:36:21
Dustin:Replying to "why is beacon stat..."
it changes proofs
00:36:25
ethDreamer (Mark):Replying to "why is beacon state ..."
It’s not, but for clients who are not prepared it’s a good amount of boiler plate
00:36:45
ethDreamer (Mark):Replying to "why is beacon state ..."
My understanding is that this field does not change proofs
00:37:10
Gajinder Singh:Replying to "why is beacon state ..."
for proofs can we please do 7688 , lets not keep tying our hands behind while driving this huge vehicle
00:37:11
Dustin:Replying to "why is beacon stat..."
does it not reorder or push anything over a power of 2? ok
00:37:30
terence:The question is whether EIP7917 introduces any delays to Fusaka
00:37:32
ethDreamer (Mark):Replying to "why is beacon state ..."
Yes that is my understanding dustin
00:37:42
stokes:Replying to "The question is whet..."
I think we all agree if it does we take it out
00:38:22
Gajinder Singh:Replying to "why is beacon state ..."
even if it doesn't change proof tree, 7688 we should do and make furture life easy for app layer
00:38:31
sean:Well not “stable” without 7688😄
00:38:55
ethDreamer (Mark):I don’t see why we wouldn’t doo 7688 the next time we have a consensus data structure change that breaks proofs
00:39:03
James He:7549 was such a headache
00:39:03
Trent:This is just CFI, why the extensive scheduling discussion?
00:39:11
stokes:Replying to "This is just SFI"
CFI?
00:39:13
ethDreamer (Mark):Replying to "why is beacon state ..."
Doing it that way is exactly the same amount of work for the app layer
00:39:18
Tim Beiko:+1 Radek, and this is why we should only add a couple EIPs to each new devnet. And if we do CFI 7688 too, I’d caution against doing both at the same time.
00:39:18
Parithosh Jayanthi:Yes CFI != SFI
00:39:21
Ansgar Dietrichs:agree with Radek - obv we can’t have 20 different EIP statuses, but we should move this to “CFI but we kick it out if it creates any significant issues”
00:39:43
ethDreamer (Mark):Replying to "why is beacon state ..."
No matter what, the app layer will need to fix proofs at least one more time - hopefully exactly one more time
00:39:49
Gajinder Singh:Replying to "I do think “better L..."
100% we should keep building the DA moat
00:40:00
Dustin:Replying to "This is just CFI, ..."
creates some risk of assumed-by-default-lean-yes
00:40:13
Gajinder Singh:scope is known
00:40:30
Parithosh Jayanthi:Replying to "This is just CFI, wh..."
CFI still means we spend some resources on it, so we cannot CFI lightly
00:40:31
Francesco:Replying to "This is just CFI, wh..."
That seems a bit less of a problem than in the past, given that we’re saying it should not be added to a devnet at least until peerdas and eof are stable
00:40:44
Francesco:Replying to "This is just CFI, wh..."
*responding to assumed-by-default-lean-yes
00:41:42
Trent:Replying to "This is just CFI, wh..."
@Parithosh Jayanthi the CFI party last week indicates otherwise 😅
00:41:46
terence:do we have spec tests for this eip we can start testing?
00:41:55
stokes:Replying to "do we have spec test..."
There are some
00:41:59
Enrico Del Fante (tbenr):We are ok to run a devnet for this at best effort (the focus is 100% on peerDas) and if first doubt or complexity, let’s throw it away.
00:42:43
Ansgar Dietrichs:meaning also, the preconf ppl should be clear that there is no shipping guarantee yet, they should make plans accordingly
00:43:33
Barnabas Busa:exact same argument as before.
00:43:37
Dustin:Replying to "meaning also, the ..."
yes, would prefer if they stopped with the "we're all thundering now towards mainnet get ready!"
00:43:50
Phil Ngo:If we’re going to CFI 7919, I don’t see why we would not CFI 7688 either then
00:43:50
Barnabas Busa:these two EIPs should go hand by hand
00:43:55
Barnabas Busa:either include both or either
00:44:02
Gajinder Singh:CFI 7919 and 7688
00:44:03
Radek:Oh, so it's 2 EIPs now... Hmmm...
00:44:07
Dustin:Replying to "meaning also, the ..."
it's apparently misleading marketing
00:44:15
Radek:Now I am against again
00:44:43
Enrico Del Fante (tbenr):We can bound them in a devnet, for tegu is ok but not all clients have 7688 ready
00:44:59
terence:For CFI, clients have to at least make an attempt to implement it right
00:45:03
Radek:Please one EIP for F-fork, maybe more for G-fork if things go well
00:45:11
Gajinder Singh:we can drop 7688 is clients are not ready by the time we are there to consider for SFI
00:46:00
NC:The sooner we get 7688 in, the more benefit we get out of it
00:46:07
Justin Florentine (Besu):reminder: we are aiming for 6 month hardforks, not 12
00:46:10
Tim Beiko:Why does 7688 help 7917?
00:46:20
Toni Wahrstätter:7917 changes the tree depth which the other solves. 7917 will work without stable containers
00:46:58
Tim Beiko:Replying to "7917 changes the tre..."
Got it, ty! With this and Mark’s expectation, I’d lean against coupling them.
00:46:58
terence:adding stable container will for sure delay fusaka no?
00:47:26
kasey:For prysm, we have a good handle on 7688 for most consensus types, but it would require some complicated changes to our state object, so there is some scope risk if we’re changing state.
00:47:26
Gajinder Singh:no need to couple, we can drop 7688 later if need be
00:48:17
Gajinder Singh:lodestar is ready for 7688
00:48:28
Dustin:Nimbus has 7688 in good condition
00:48:42
Barnabas Busa:any client has made no progress of 7688?
00:48:56
kasey:Replying to "For prysm, we have a..."
The state essentially does not use our ssz library because of merkleization optimizations.
00:49:05
Marius:Small forks lfg
00:49:07
ethDreamer (Mark):I need to confirm that we’re not crossing a power of 2 boundary but that was my understanding from the last time we discussed it
00:49:11
Barnabas Busa:we can’t do small forks
00:49:14
Barnabas Busa:lmao
00:49:22
Dustin:3 months seems excessive for deployment/testing concerns
00:49:32
Sophia Gold:I think six months is reasonable
00:49:39
Sophia Gold:Maybe you say 3 and end up with 6 :)
00:49:49
Justin Florentine (Besu):Replying to "we can’t do small fo..."
difficulty bomb diffusing has entered the chat
00:50:26
Gajinder Singh:Replying to "we can’t do small fo..."
but we can 6mnths
00:50:35
Tim Beiko:Replying to "Maybe you say 3 and ..."
The only way to do it 😄
00:51:51
Barnabas Busa:we don’t have a way to test small forks
00:52:14
Ansgar Dietrichs:love a good acd pep talk :-)
00:52:27
Tim Beiko:amen
00:52:28
Phil Ngo:So we should DFI both and just try to get Glamsterdam faster because we limited Fusaka
00:52:54
NC:So we couple 7917 and 7688?
00:56:28
Dustin:relays/builders wait intentionally to return information anyway until it's useless for the proposer
00:56:49
nflaig:we usually receive block via gossip sooner than from api response
00:57:08
Toni Wahrstätter:What about just some 200 response. What would the payload give me without the blobs?
00:57:11
Manu:Most relays apply a 1 second delay
00:57:16
Enrico Del Fante (tbenr):And even sometimes we timeout on response 🙂
00:57:28
Dustin:Replying to "we usually receive..."
exactly, we hae a bug filed around this even, because it looks like it "fails sending" because of gossip val checks
00:57:33
Manu:Between publishing block on P2P and responding to the HTTP request
00:57:42
Francesco:It’s completely useless to return anything to the proposer, if the builder/relay wanted to screw you over they could just do it
00:57:45
Enrico Del Fante (tbenr):No data in response
00:58:53
nflaig:202 status code would be better and not return anything
00:58:54
Toni Wahrstätter:Return a positive response after the relay propagated
00:59:03
Oisin Kyne:would this impact the trust assumptions/risks faced by peerDAS? if we have a handful of relays only, how sure are we blobs will be available on p2p?
00:59:42
Gajinder Singh:good with empty response
00:59:51
Francesco:Replying to "would this impact th..."
It doesn’t. If the relay doesn’t publish the block or blobs, it will not end up being canonical
00:59:55
Enrico Del Fante (tbenr):Replying to "202 status code woul..."
Status code is actually nothing 🙂
01:00:19
Toni Wahrstätter:does "leave it alone" mean full response with blobs?
if so, then no, make the response small but existing.
01:00:28
Dustin:the main requirement would be that the builder API specs explicitly require the builders/relays to propagate things
01:00:30
Dustin:it doesn't right now
01:01:04
Enrico Del Fante (tbenr):Replying to "the main requirement..."
IIRC it has been specified somewhere that they are responsible