All Core Devs - Testing #102

Transcript

Justin Traglia: Good morning, everyone. One minute, and we'll get started. Good morning, everyone. Let's get started. This is All Core Devs Testing 102.

Is there someone here from, protocol DevOps who can give us updates on networks?

Barnabas Busa: Yeah, I can give an update on the Heze 2 and 3. So, we have been spamming the network a little bit here and there. to try to break it, and so far, the only issue that I've seen was the issue that, we've been discussing in the intro regarding the, Get payload, timeout. Issue. Maybe we can come back to that topic in a bit. But other than that, everything seems quite stable on the headset appliance.

Justin Traglia: Okay, nice. And how are the Glamsterdam devnets and Sepolia?

Barnabas Busa: Sepolia is still stable. I'm sure D'Amut is too stable.

Justin Traglia: Okay. Great. And remind me, had Hoodi fought today, when would that have happened?

Barnabas Busa: And it would have been 4 hours from now, I think? 4 or 5 hours from now, and that will not happen.

Justin Traglia: Yep. But we still need to keep an eye on it, so… okay. Cool, any other updates on networks?

Stefan Starflinger: We have, Bogota devnet 1 still running. I'm onboarding Nimbus EL. There were some issues that were fixed. And it's running pretty well. I haven't run any fuzzing there yet, but I'm thinking of doing that before starting Bogota devnet 2. And that the tests will be ready pretty soon for that, I think, today or tomorrow. From what Spencer wrote, And that should be ready to launch, but I think we still need some branches from clients for it.

Justin Traglia: Okay. Anything else? Okay, thank you. Moving on, Toni, are you here to… Give us updates on the 8037 and 8038 issue that came up last week.

Toni Wahrstätter: Yeah, I'm happy to do so. So, last week, ChainSecurity provided this, bug report that 8037 and 8038 interact with some opcodes in a way that we weren't anticipating or weren't looking into, I guess. And… So, just to get everyone onto the same page, there are basically four issues. One of them was always known, that if you reprice opcodes, that, if you hard-code gas within contracts, that that can break. And this is not the new part about this one. But then there is also an interaction with gas left, which is used in some of the contracts, and based on what Jayani reported, gas left could suddenly increase, and this was something new. And similar applies to, gas left,

Similar applies to refunds that suddenly could fund execution of a path that Before that, couldn't execute. So this is just a quick TLDR of the issues, and right now, it felt like over the weekend, people… analyzed the situation more carefully. So a bunch of people used AI to dig deep into that issue, and my personal feeling here is That we have a quite good overview over the… the blast radius of this… of this bug, of this vulnerability, and now it's about reaching out to the affected parties and make sure To discuss next steps with them. And… People already started discussing spec changes and so on, but right now, it feels like we don't have certainty

to… to do so, so I don't think we are ready to… to schedule Hoodi, so my feeling is we should delay that by at least a week. And then, keep discussing the topic.

Justin Traglia: Fredrik.

Fredrik Svantes: Yeah, we also engaged with ChainSecurity and Dedaub to do a more comprehensive analysis, and they're… ETA is… Two weeks to provide a report. So my recommendation would be to wait. Well, at least until we feel more confident, but that could be at the end of this. review process that's… ChainSecurity and Dedaub is also doing, on top of the internal stuff that's Toni has been discussing now?

Justin Traglia: Was that 2 weeks from today, or 2 weeks from, last Thursday?

Fredrik Svantes: Most likely today. I… I don't… I'm not foolish, or… I mean, we reached out to them, At that point. But kind of came to an agreement on Friday, I guess. So I would probably count it from today.

Maria Silva: Yeah, I… I would also add that, besides the, analysis that we've been doing internally, and that, Fredrik has talked about, the… with the, security researchers, I think there's then the outreach work as well. As Toni was saying, like, the key thing will be First, we understand the affected contracts, then we reach out to the teams, and the first… The default will be To understand if they can fix it. And if they can, then that should be our default. and only if… they can't fix it, and the blast radius is big enough, would we then consider spec changes? And the reason for this is mostly because Spec changes are expensive. In many cases, it's not even possible to fix it without undoing the entire EIP, which would mean not raising the gas limit.

In some cases, and so I think we need to look at, first spec changes should be targeted, so they shouldn't be… just we do everything. We should try to, if we find an issue. cannot be fixed, has a big blast radius, then we work towards fixing that issue in specific. So, and change it As least as possible. And so… so this is to say that we should try as much as possible to not change the specs, and then only change it Doing, like, the least changes as possible. And also because this is kind of spaghetti, right? Like, if we change some things, then we might break other contracts that we are not expecting. So we would need to redo the entire analysis again.

So yeah, so I think this is how we are currently looking at it, so we are rushing to have a good analysis of the blast radius, contacting the teams, making sure that they can fix it, and only if they can, then we'll consider spec changes.

Fredrik Svantes: Yeah, and also on top of, Analysis on the contracts, like, if there was to be, some type of a major spec change, then we would need to… well, we would, in our case, need to reduce Sepolia… And we would have to… creates new tests, we would have to do another security, review. And this is gonna take… quite a lot of time, so if… Yeah, like Potuz says, in that case, we just probably have to ditch it and just start something new. It's quite an invasive thing, and if… I mean, there will probably be contracts that cannot be upgraded that are found, but then the question is, are there mitigating factors to that? could… Could this contract be,

exited within a reasonable timeframe for users and so forth. I think it's gonna have… after this analysis is done, it's gonna have to be some… probably… Discussions around what to do with contracts that cannot be upgraded, and… Is it reasonable? For the users of those contracts to exit, and… Use a new contract which is compatible, etc. That feels like something that we would… We're doing after we've done the outreach, and… Figure out the entire blast radius.

Justin Traglia: Łukasz?

Łukasz Rozmej: So in my opinion, because we don't know what would be the correct path yet, we shouldn't box ourselves into one of those two alternatives, and we should keep exploring both alternatives, that is, spec changes and not spec changes in parallel. So, if we get the feedback that we do have to do spec change, then we would be further on that path than not.

Justin Traglia: Maria.

Maria Silva: I would add, I don't disagree with you, Łukasz, and I do feel like it's valuable to do it, and I think we should do it, and I'm also reviewing your PR and working on a doc to summarize it, but I think the current PR you have does a lot of changes that tackle a lot of invariants, and I think instead, what we should do at this point is, like, go invariant by invariant, and try to think what the targeted fix would be. So that we can know, like, now this contract is breaking because of X, then I can pull the spec change I need. And this is not, like, a bundle of a lot of changes, it's, like, the change that fixes this.

Also.

Łukasz Rozmej: So, this is kind of how I arrived to this, to this solution, so, yeah, sure. So this wasn't, like, one-shotted in any way or anything, this was, I don't know, at least 12 hours working with, cross models from, Opus, Fable, Matos, and Astra, and reviewing each other and trying to To find holes in this, so that's why it… The end result might be too big, I agree, but it might be trimmed, but that was kind of how this was growing, because… Each other found holes in the previous work, so to patch all.

Maria Silva: Right, right, but… But if I understand correctly, just make sure I understand, the starting point was the report from ChainSecurity, right?

Łukasz Rozmej: Yes.

Maria Silva: Which, which reports a bunch of different invariants, not just one. And so I think your starting point was already a bundle of things that need to change, and we might not need to change everything there.

Łukasz Rozmej: Might be true.

Maria Silva: So this is the exercise I'm trying to do on my side, and I'm… And I'm also using your work, like, it's not… I'm piggybacking from you, I'm just trying to break it down further so that we have more targeted changes if we need them.

Fredrik Svantes: Yeah, I agree with you, Łukasz. I mean, I… this should be done in our case. In case… For some reason, something pops up that makes it necessary. I still hope. it won't be needed, but I… yeah, I do agree that it's valuable to do this exercise. Just in case, so we don't end up in 2 weeks, or 3 weeks and see, and we have to start at that point, because that's gonna delay things even further. But… For now… It appears that it won't be necessary? Hopefully, at least. But, yeah. I mean, I am wondrous support.

Justin Traglia: Sorry, Toni?

Toni Wahrstätter: Yeah, just to add, also the… the potential spec change that we might be doing after all, I don't think we will, but… the one that we are discussing. It will also depend a little bit on the result from the outreach, because there are different things that are breaking for very different reasons. Like, we have identified four different, coding patterns that break, and those are very independent from each other. So, of course, there are solutions in the specs, that kind of tackle them all at once, but… it might be much simpler to even tackle them individually, like Maria said, like, trying to make it very modular. Not sure if that's possible, but right now, just to stress that again, it doesn't look like we will need spec changes. All the findings that,

were, like, ranked as high severity, seem like they are fixable, and parties are aware of that. So, I would just delay the decision, until next week or two weeks. Sorry, not decision, the scheduling for Hoodi.

Justin Traglia: Yep. Okay, anything else on this topic? Otherwise, I think we should move on. Okay. Dimitri, are you here to give us, Alright, to talk about your proposal to change the builder onboarding logic now that Hoodi has postponed.

Dima Gusakov: So, the link is attached to the agenda, and the… The gist is that… builder onboarding, within Glamsterdam, what happened, like, at the moment of the fork, through the… Validator deposit queue, and there is an invariant that some of the protocols, including Lido. heavily or not heavily rely on. The invariant is that whenever you make a deposit to a validator. What you expect for sure is that after making this deposit, no matter if this deposit has been attacked by your node operator, for example, and has been front-run. or not. At the end, like, once you've made a deposit, there will be a validator with this public key. added to the registry, sooner or later. But this is an inevitable outcome right now. With this builder onboarding process, this invariant breaks, and now, with the current spec, if you

make a deposit to a Validator, pre-Glamsterdam, and then this deposit is front-run by your node operator with the deposit message that contains 0x0B, prefixed to the withdrawal credentials. Then, after you made this deposit, your deposit will never transition into a validator, but it… rather, your deposit would be credited to a builder. And that creates, several potential issues, like, including on Lido's side, where the system is built around the assumption that some sort of a validator would appear, and you would either be able to prove that the validator has appeared with the right withdrawal credentials, or with wrong. Well, in this case, there will be nothing to prove, and a patch is, could be required, or, like, pausing deposits, or whatever workaround on the application layer.

And I think somewhat similar, things apply to the other protocols. I'm not quite sure, like, I never did a detailed analysis on the severity for the other protocols, but I do think that a lot of staking protocols might rely on this assumption and this invariant. So the proposal is to change the way how deposits are processed. on the Glamsterdam hard fork, and that only deposits that have 0x0B prefix in the withdrawal credentials would be credited to builders, while any other deposits, including deposits with the same public key. For the Validator would indeed be processed normally, so they would not be picked up. From the deposit queue at the moment of work, and later on will be processed as normal.

This is a minimal change. I think Potuz did a research on that, and found no issues other than the fact that builders should be aware on how they should make top-ups if they want to have not just the initial deposit for the builder. but also top-ups. So, my call here is, provided that we now have a little bit of a leeway to test, to implement and test this… this thing, to fix this thing, and I guess On the last call, we discussed that. There was a major alignment that the issue is real and it's better to be fixed, though the main concern was that it would break timelines, but now then, when the timelines are already broken.

I highly ask you to consider fixing this thing, Given that we now have time.

Justin Traglia: Oh, thank you. Clients, what do you think? Okay, I support this PR. I know Nico and Potuz also support doing this. I've chatted with other CL clients, and I believe they're also support doing this now. Is there anyone that does not want to do this, or thinks that this is a bad idea? Oh, sorry, I didn't actually see the comments. Support from Lighthouse as well. Dustin… He says it's okay.

Dima Gusakov: Yeah.

Justin Traglia: Understood.

Dima Gusakov: Dustin's concerned, as far as I know, the situation that I've described was not possible on Sepolia, and hasn't occurred on Sepolia. because of the way how deposit contract is made. So, technically speaking, it would not change anything compared to Sepolia, except for this very moment of forking, which was not affected on Sepolia anyway.

Justin Traglia: Yeah, that's right, it shouldn't affect Sepolia.

Dustin Brody: Okay, I mean, it obviously won't affect Sepolia in an ongoing way, of course. We're in Gloas now. I'm also keeping in mind, and I understand that… that there's discussion and, you know, at various timescales of when to, deprecate Sepolia, and… but… but without committing, to anyone firmly yet, because we don't know, pending 8037, et cetera, et cetera. The question ends up being, if… I mean, I think the most… either, sort of, let's say Genesis syncing, yes, yes, I know, like, weak subjectivity period, but let's say you want a Genesis sync, or we sync from before this time period, or backfilling, and those are the scenarios I just want to make sure are… can be done, or would be able to be done, using post-Sepolia Gloas code on Sepolia.

That's the question.

Justin Traglia: Nico?

Nico Flaig: Yeah, so we didn't do the builder onboarding on Sepolia, so that's the only case where it could cause a divergence. So, for Sepolia, it will not matter in the cases you mentioned.

Dustin Brody: Okay, fine, done.

Justin Traglia: Okay, great. I think we should just… let's merge this PR and make a release sometime this week. Alright. Moving on. Barnabas, are you here to discuss, raising the Get payload timeout and the inclusion list forkchoiceUpdated timing?

Barnabas Busa: No, because I opened a new PR where we would basically get rid of the definition. We were just discussing this in intro. Just a few minutes ago. So the idea was, that the timeout should just go away, and that the EL should reply as soon as possible.

Justin Traglia: Yep, thank you. I mean, that makes sense to me. EL… since we have EL clients here. I mean, does that make sense? Or is this doable?

Daniel Lehrner: Yeah, so it's definitely doable. As I explained on Discord, you know, we were waiting on purpose to build a more valuable block. But now, through the discussion, it seems like that's actually not what we're supposed to do. So now the spec for me is clear what should happen.

Justin Traglia: Got it, thank you. Fabio?

Fabio - Besu: Yeah, I want to add a possible interaction with FOCIL. When, we are… Ask it to include? A list of, transaction. It is worthless to create an empty block at the beginning, since it will not satisfy the inclusion list. So, with FOCIL, it's possible that the first There will be a bit of delay, because we tried to build the block with at least only the inclusion list transaction. So it's not the empty block like it is now. But it will be a minimal block. with… Only the inclusion list transaction, because otherwise it… it is worthless to return something. Just wanted to… Raise this, because…

With FOCIL, there could be some more delays in GetPayload.

Justin Traglia: Nico?

Nico Flaig: Yeah, I'm mostly, questioning, like, how the CL should call GetPayload then. Because if we have builders configured, we can do this call when the GetHeader respond is returned, right? To give the EL the max time to produce a better local payload. But that highly depends on, like, how ELs behave, like… And I'm not sure that's clear from the spec, if, like… should be an instant response, right? But also, Dustin is saying, like, there are payload timeouts, so…

Dustin Brody: Yeah, I actually think this is useful because it clarifies the intent, and, Because this is what… when we were seeing this, when Nimbus CL was seeing this, specifically on the devnets from Reth as it happens, we didn't see it from Besu for whatever reason. We would see these consistent timeouts on GetPayload, and the problem was, it was like, okay, we actually could say, okay, something was going wrong with timing out, fine. But was the fact that it was getting even vaguely within an order of magnitude close to timing out also a problem, or was that just, like, doing a spec thing? And so I think it's kind of useful to clarify… for the spec to clarify that one way or another here.

Justin Traglia: I mean, it's already been merged, but do we need to agree to this? Today. Is there anyone that's against it, or… Toni's asking, does payload execution now have a deadline? I don't know that. Okay. Yeah, I don't wanna say.

Please review that PR, even though it's already been merged. If necessary, we can unmerge it. And let's talk about this more. at Devcon, and… or the next ACDT. Alright, I would like to bring up that, we'll be at Devcon this time next week, and that we should skip ACDT on November 2nd. If we decide to do this, ACDT103 will be on November 9th, moderated by an EL dev. Does that sound fine with everyone? Okay, great. Any other topics you guys would like to discuss before going into the breakout calls?

Alright, I just… oh, Mario?

Mario Vega: Yes, I just wanted to point out that there's no EL breakout topics. Should we just keep the EL discussion here, or… What do EL Devs want to do?

Justin Traglia: Toni, what does the thumbs up mean, exactly? Keep it here.

Toni Wahrstätter: Yeah, leave the room to the CL.

Justin Traglia: Sure, I guess that's fine. Okay, Ashum, are you here to discuss verifying backfilled envelopes for exited builders? This does sound like a bug we need to fix. Or is there anyone here that could speak on his behalf? Pretty much there's issues, it's difficult to verify. Difficult to verify envelopes for exited builders when syncing. In his comments on the agenda, he outlines a few different proposals on how to fix it. Spencer? What do you mean, it's perfect consensus?

Spencer Taylor-Brown: Hey, yeah, sorry, I was making a joke with regards to 8037, sorry.

Justin Traglia: Oh, sorry. Okay, then Potuz, are you talking about… When you say the hash is enough? Are you talking about this or something else? Okay. Pawan from Lighthouse says that we just recalculate the block root. Perhaps tough. Potuz, do you want me to unmute you? Gee, I can't.

Potuz: Oh, I found the button. I'm sorry, I'm walking. I'm talking about backfilling. I don't understand why this… is that a problem. If you're… if you're already backfilling and you trust your current checkpoint. and you're only doing backfilling, then the hash… the payload hash is good enough. You don't need to verify any signature.

Justin Traglia: Let's see.

Dustin Brody: The premise here is that we want to be able to serve the envelopes through ReqResp. as well, and part of that is a signature.

Potuz: Yeah, if you need to serve… if you need to serve the full envelope, then yes, you… then you… you might be getting, A block whose signature is inval… the signature field is invalid.

Dustin Brody: Right, and that's the question, right? So, so, if… if the stated… and that's what we would like to resolve, if the stated, intent, design, I don't know what we are here to do, of the spec, is that, the ReqResp on that, from… that… for the backfilling, note is simply unimportant. They are not expected to provide that. Number one, that should be made clearer. Number two, then there should be a way to signal this, and or it should be… there's some condition under which that we say, okay, but the… you know, if, let's say, you would usually want, let's say, the 5 months or whatever of the envelopes, or… but no, actually, no, only store… I mean, we were joking about this, you know, internally, but odd, should we only go back not no earlier than finalize? Because that's all that's even vaguely useful, except for ReqResp.

if we can't serve the signatures reliably anyway. But right now, it's just kind of misleading.

Justin Traglia: any other thoughts on this from other client Devs?

Pawan Dhananjay: So you… you would… in order to make sure that the signature is correct, we would also need to, have the state for the builder who signed it, and the builder might have exited by the time we are backfilling it, so… I haven't seen, like, the agenda, if you have already proposed a solution for this, but, like, that was the issue that we ran into when we were trying to… Verify signatures as well.

Dustin Brody: This is… this is… True. Well, this is the same… this is the issue indeed. This is precisely the issue. Oh, I see, oh, I see Sam's here, I don't know if he wants to… this is kind of his…

Potuz: I'm s… I'm sorry that I'm interrupting, I think, someone. But there's no need to verify any signature ever. So, we're making the point of verifying a signature that shouldn't be verified. That signature is there only for gossip. It's only to prevent a DOS at the gossip time. So when serving this, the receiver of this should not even care about the signature.

Dustin Brody: then the spec should make this clear. The spec should make it clear that this is… and you can argue it actually kind of does, because we looked at this and found that, for example, for block backfill, the spec does absolutely say you verify signatures, as I think we all do. and it specifies that all the way back to Phase 0 in the P2P interface document, and there is no similar language for envelopes, and maybe that's fine, because of, as you say. But if that's the case, that should be made clearer, because… yeah. And just that… and if that is the case, then it is probably useful to say, and here's if, you know, there was an, you know, a question about, well, did we have proposals, things like this? Maybe we say it's zero.

Right. Like, the signature provided is zero, so we're not providing a potentially invalid signature, we're providing a signature which we're saying we don't… Think as trustworthy. But either way, it should be specified.

Sam | Nimbus: Yeah, and I think the main approach that I would like to propose Was, if the signature is not verifiable in below checkpoint… In the case that… backfilling. then… Should we remove the signature in the by-range request response endpoint so that… to make it clear, or… To make it stated clearly in this consensus spec to… So that, yeah, we do not need to verify that. Yeah, I mean, we can… Gipping the signature in by range, but… We should state it clearly in Consensus-specs, where that signature is not helpful. In that particular period, or respond.

Justin Traglia: We could just add a note to the spec. Instead of removing the signature from the request. Or, response.

Sam | Nimbus: No, I mean, we do not need to remove anything if we want to keep the signature in the by-range response, but this is stated at a statement, like, to clarify that that signature is not very helpful for verifying that envelope. This is what I mean. So, nothing changed, it's just… clarified… a clarification into this Consensus spec. So that we're, yeah, we all align with that.

Justin Traglia: Yeah. I mean, I'm fine with that. I have Potuz thumbs up. Assume that means support.

Sam | Nimbus: Yeah, sure, I can create a PR. Regarding that.

Justin Traglia: Okay, Pawan, does that also sound fine to you?

Pawan Dhananjay: Yeah, but… yeah, that sounds good. I'll… I can review the PR.

Justin Traglia: Okay, thank you, Sam. I'll also review whenever that's posted. Okay. Anything else you guys would like to discuss?

Nico Flaig: Should we talk about the gas limit, gossip check, and, like, the transaction maximum?

Justin Traglia: Oh, yes, actually, that'd be great. Can you lead that, Nico?

Nico Flaig: Yeah, so maybe I can quickly share the check in the chat. So basically, when we receive a payload, so in class. And, we already know the bid. We can, like, limit the max amount of transactions by simply checking the gas limit that the bid specified against, like. Some minimum transaction gas that we specify. Like, that number needs to be well-defined, I guess, but you could add a lot of wiggle room, so we don't underspecify it. And we could basically reject payloads based on that limit. And, I guess you could, enforce this really early in the gossip check. And probably even during deserialization, so… It's just a way to harden, like, the P2P gossip, yeah.

Justin Traglia: Toni, to answer your question, With ePBS, it's a bit easier to broadcast and propagate, invalid payloads, which may be above the gas limit, and or be malicious. This would be just a simple check to limit that.

Toni Wahrstätter: Right, I understand, yeah. There are similar things on the EL, but usually it's just not spec, but client optimization. Like, it's… it's… having this check could be seen as a client optimization that allows clients to

Justin Traglia: Not…

Toni Wahrstätter: Recognize to identify invalid Payloads earlier, or invalids.

Justin Traglia: I sort of… I mean, I agree with you, it could be a client optimization, but that would limit it to an ignore. If we want it to be in a reject, it has to be in the spec.

Nico Flaig: Yeah, just to add to that, right, so it's, on gossip, we don't validate the payload, in that sense. We don't wait for the EL to tell us that it was valid, we just forward it anyway. And if one client has this check and another doesn't, it means that one client forwards these payloads, and another would have to ignore them, but as Justin said, like, if we have this in the spec, then we can reject the message and, like, downscore peers that send us this.

Toni Wahrstätter: But you don't forward multiple payloads today, right? Because this would mean you would DOS your EL. So there… there is already something that is blocking a builder submitting multiple, right?

Nico Flaig: Yeah, like, you have a seen cache, right? That prevents it But when you receive that payload, you don't know whether it's valid or not.

Justin Traglia: I'm supportive of this check. I mean, it feels so basic. I just don't like having to define min transaction gas in the CL. That's my only complaint. maybe a dumb question, but what is the minimum transaction gas? I think I heard that it was 12,000? Is that… So accurate.

Toni Wahrstätter: This is something that changes all the time. For example, it will probably change again with Frame Transaction. So to me, just fundamentally, it feels wrong to, like, connect the EL with the CL in a way where the CL suddenly needs to know, like, minimum Transaction gas values. that sometimes even depend on the gas limit. For example, the state cap.

Justin Traglia: Yeah, you're not wrong. Sorry, there was a southern house. Dustin says he's not really against it. And jochem says that the minimum gas limit is 20… 21,000 before Glamsterdam and 12,000 after Glamsterdam. Nico and others, how would he feel about just leaving this as optional for clients and just ignoring the messages? Like, is that sufficient and still useful?

Nico Flaig: Yeah, I would say it depends if, like, every client anyway implements it, right, then might as well define it in the spec. I do agree with, like, the… I also don't like having this EL-specific constant. I don't like the… bit validation, gas, target validation, I don't like that either, but… I don't know, I mean, we could, keep it maintained on the spec across forks, right? If there's a new constant that we need to use.

Justin Traglia: Yeah. Potuz?

Potuz: I think it's fine to have a CL flag, it doesn't need to agree with EL in any way, it should be a lower bound. We can just put a ridiculous value, which is very, very low, and still will save all of the DoS that we see from these deserializations. So even if we put, like, something like min gas to be less than 1,000, It'll be absolutely fine, and we can envision a time where it would take several years for the EL to reach such a gas limit.

Justin Traglia: Nico, do you have a PR for this?

Nico Flaig: No, not yet.

Justin Traglia: Okay. I'm thinking you should make one, Then we can discuss it a bit more, and then maybe merge it today or tomorrow, or sorry, maybe tomorrow. Yeah. Potuz's idea also sort of makes sense, though I'd rather just… I feel like I'd rather just keep the… Or sorry, use the minimum transaction gas for that specific fork. Because it would… Just be more effective. But, not a strong opinion. I'd have to think about it more. Okay, I think we should move on to another topic. Barnabas, somewhere you mentioned… Can we discuss the final form of Consensus specs? Can we expect shorter slots to be merged in this week?

It's a great question. I don't know. Jaehoon, are you here? I guess not. client teams, Potuz, I mean… I don't know what to say. And we should… we merged, shorter slots into… the Heze spec. Potuz is saying, fine by me if we S… fine by me if we SFI it at ACD this week. I… I mean, I don't think that that's gonna happen, personally.

At least… I mean, we may SFI… feature in the mechanism, but we might notify Or, like, agree to a specific slot duration. And NC's asking, didn't we agree not to do quick slots in the next devnet? So, don't merge. Yeah, I mean, Barnabas and ETH, sorry, DevOps, I think they launched the devnet themselves with quick slots. And a 9-second slot duration.

Barnabas Busa: Nope. So the idea was that, By the time we figure out how we want the spec repo to look like, we should actually have some testing happening as well. Yeah, I'm still not quite sure how we want the… Consensus-spec repo, to look like, but we already have another top for a week. That's perfect, so… I feel like if we just have, like. the specs in some open PR, and at this point, I think we have, like, 3 different PRs for the quick slots implementation, so this is also quite confusing. I would personally much prefer if we, merge in… the spec that we want to target for the following devnets, instead of having open PRs. And I just don't think it's realistic to have an SFI state before a stable spec version.

And the only way we can have a stable version is if we also run it on the iPad.

Potuz: It's… It's going to be circular, but I disagree with that segment. Again, I want to keep things out of the main spec if they are not scheduled for inclusion, and I don't think that we need to have them merged to be able to test them.

Barnabas Busa: So you're happy with, basically, 3 separate PRs and unsure which commit hash to target for your test?

Potuz: I… I am not sure what is the best solution to this, and I acknowledge that it is more work for the spec maintainers, and for the feature writers for these features. If they want to have them tested. But I think that it should be on the people that are writing these features and the people that are maintaining these features to have the tag that would give us the test vector so that we can actually test. So I would want to have a tag for the devnet. And that tag does not need to come from the main branch.

Justin Traglia: Until clients… I would say until a majority of clients agree to merge it into the Heze spec, it should remain a feature. But I don't think that we need to wait for it to be SFI, for it to be merged. But, yeah, so when a majority of clients want this, I'll merge it, or will merge it. I don't want to do, like, some complicated branching strategy, like we discussed on Discord.

Matthew Keil: I think the only contention, at least from my side, is merging with 10 seconds. like, if we merge the machinery and have the option available so that we can test with it, I think it… meets at least a lot of the opposition that I've heard, to… to getting it merged. The biggest issue is forcing the issue of shortening the slot times.

Barnabas Busa: Can we do 12 seconds for mainnet spec and 5 seconds for minimal spec?

Matthew Keil: I mean, that to me feels reasonable. as long as the mainnet time doesn't change, so that we don't back ourselves into a corner, and we can still do the testing, which I do think is a really good, a really good feature set. I think I'm full-throated, in agreement.

Potuz: That would… that would break our testing. If you change the minimal spec, it would break our testing, so we would not be able… we would be forced to have Shorter slots on the… our trunk branch. Or skip the tests.

Matthew Keil: I apologize.

Potuz: Which, again, this is… this is my problem.

Matthew Keil: I agree with Potuz, like, as long as the time stay… because I forgot, it's not 5, it's 6, I believe, on minimal. As long as the times remain the same with what they are today. I don't see a big issue.

Barnabas Busa: So it'd be.

Justin Traglia: There you go.

Barnabas Busa: How do you plan to test, shorter slots? If you leave the original numbers.

Potuz: the way.

Justin Traglia: Not sure.

Potuz: It shouldn't be complicated branching. It should be just one branch.

Justin Traglia: What do you mean? Like, we currently just have a singular master branch.

Potuz: You should… we keep… we keep… so we have a master branch that has Heze, has each directory, and we just keep one branch, which is our develop for the Consensus spec, and that branch is targeting whatever we're going to be testing.

Justin Traglia: we don'.

Potuz: There's one branch that needs to be happening that is Testing Branch.

Justin Traglia: That was a complete idea. And you shouldn't be a…

Potuz: It shouldn't be even a branch. It shouldn't be even a branch. It should be just always the rebase of these features on top of Heze, or on top of whatever fork we are now. The whole point is that If I am writing a feature for the spec, I should not be… it should not be on me to be rebasing my work on top of features that are not mandatory.

Justin Traglia: I think we have to keep it as a feature for now, for Barnabas. And then maybe we can discuss it more at ACDC next week or later, but I don't think there's support for merging it into Heze right now.

Barnabas Busa: Could we maybe merge them the same times? 612. Perfect. That would break nothing, basically.

Justin Traglia: I don't know. I mean, we could keep the same times, or the same slot durations, and merge it, but… I don't think that really… I'm not sure that really… fixes Potuz's core concern. And others.

Barnabas Busa: Yep.

Justin Traglia: Alright, let's discuss this more on Discord and at ACDC, maybe, or just… Sometime more in the future. Are there any other topics, we'd like to discuss? Alright, well, thank you everyone for joining. I will see you guys at ACDC on Thursday. Bye, everyone.

Jochem Brouwer: Thanks a lot.

Kevaundray Wedderburn: fair.

Jochem Brouwer: Bye-bye.

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