All Core Devs - Testing #79

Transcript

Parithosh Jayanthi: Hello, everyone.

Jochem Brouwer: GM, GM.

Parithosh Jayanthi: Let's wait another half a minute before, before we start off… Okay, sounds good. Let's start. So, first item on the agenda is a summary of the interop event. We've had the blog post go up live, but besides that, we've had some, really nice updates from both the block-level access list as well as replacing Glamsterdam and, fossil streams of testing. Does anyone want to give a brief summary from each of their lines of…

Lens of work. I'm just gonna call on people. Barnabas, do you want to give a brief summary of Interop from the Amsterdam perspective?

Barnabas Busa: Yeah, sure. So Glamsterdam… Glamsterdam started out, pretty strong. We had a working DevNet up and running by, Tuesday, and, then we crashed down, and we've been trying to get, the Glamsterdam.net, stable, into a stable environment. Currently, we seem to have issues with a few clients. we are still unable to sync on Lighthouse, and The envelope serving from Teku seems to be incorrect, and we might have finalized a invalid state because of this on Glamsterdam.net3. We've been discussing this issue on the ePBS channel. I think, I think we could discuss it a bit more later on in the call, but, maybe not right now.

Parithosh Jayanthi: Yeah, that sounds good. Well, not good, but yeah. Stefan, do you wanna give a brief update on block-level access lists in ED37 during interrupt?

Stefan Starflinger: Yeah, sure. So, during interop, we spent a lot of time finalizing the spec for 8037, and we made some small iterations during interop, made pretty good progress. bal-devnet-6 is close to finalization. There are still some issues that, we can't resolve with bal-devnet-6, and that we will resolve with a final BAL and 8037 DevNet, which I can share the spec for, but there seems to be some issue with the HackMD right now, so I will just share it as a guest. And I'll see if I can get that fixed. And the idea is, to keep everything as stable as possible, for about DevNet 7, incorporate the benchmarking. into, bal-devnet-7 from BileDevNet 3, where it has been running pretty stable. And to make some of the optional, things, like, East 70,

And East 71, required, for, this final execution there on the BAL DevNet, and then to merge, everything into Glamsterdam DevNets, after this.

Parithosh Jayanthi: Thank you. Yeah, we'll talk about DevNet updates immediately after the interop updates. Maria, do you want to go for repricings?

Maria Silva: Sure, can you hear me alright? Okay. So on repricing side, we, were working… sorry, during interrupt, we were working on optimizations, and as Stefan was saying, they will be merged to all DevNet 3 branches. And we got some, initial preliminary numbers for 7904, which is the compute EIP, and 8038, which is the state access EIP. I'm still working on updating the final versions of the EIPs, and the reason for that is that we still After coming back, from Interop, we, found a few more optimizations that, clients are working on, and so the numbers we saw on Interop are not yet, final, and so I, I expect, by next week, to be able to give a more concrete update on 7904, so the compute EIP, and I think for the state access EIP, that will likely take, a bit more time, but, but yeah, so I think now we are just trying to

Have more stable optimizations, and fix some, outliers, to see if all clients sort of start performing in a more, closer way, so we don't have, like, one, client that is, very different from, from, from all the others. So yeah, still some work to do there, and yeah, I'll give, an update next week.

Parithosh Jayanthi: Awesome, thank you. I'm just gonna give a brief note for FOCIL. There was a, FOCIL DevNet that was worked on during the week. I know that a couple of clients were able to get Interop working, and there's going to be more work put into the Hegota line of testing, but, yeah, for now, that was the, I guess, brief version of the Hegota line. Do we want to dig a bit more into what's going on with, Glamsterdam DevNet 3? Is there any specific asks or something, Donovous? What's broken on the DevNet, or what's the current status?

Barnabas Busa: So, right now, we are trying to figure out if Teku is serving the invalid envelopes, and if they do, we might, you know, need to restart the chain, because I don't see a way we could recover from there. Oh, POTUS, yeah, POTUS probably has more info. Yeah, sorry, I didn't see the chat.

Potuz: I don't… I don't think we… at least I don't have any evidence of an invalid payload being, served. The problem is sync itself. I don't know about Lighthouse, Lighthouse is having problems also with, like, getting payloads. The problem that Prysm is seeing is that, we are out of sync for whatever reason, most probably because we pushed something on the branch, and we've restarted, and then we start getting… requesting blocks and payloads by range. And the problem we see is that clients are not returning compatible blocks with payloads. Which is the damn issue of not… of, like, not going with the EIP that allowed us not to serve payloads. But anyways, the problem is that we are downscoring peers because they serve as blocks that are not compatible with the payloads that they themselves serve as.

And therefore, we just ban them, and then we end up not being able to sync.

Enrico Del Fante: One question, because I haven't… Had the time to look into this. So you're saying that, as you probably wrote in the, in the chat. Are we possibly serving hot payloads? as fool, While our canonical chain is instead empty, so…

Potuz: No, it's actually the other way around. The errors that I found are mostly that you give us, like, block A, block N, then block N plus 1 in the range, and then for the same range that would request payloads, you didn't give us the payload for N. So then, when we tried to interlead them, we realized that the same pier on the same range served as blocks that were based on full. But, the payload wasn't there.

Enrico Del Fante: Okay, so we need to figure out on the logs, spend some time there, so…

Potuz: But we could just, like, drop the whole thing and not download the payloads and not serve the payloads. That would be much, much easier.

Enrico Del Fante: That's another discussion. But on the other way around, it's just fine to you, because we serve all the payloads that we get, even if it was reorgan.

Potuz: No, that would be also a banning situation. We need…

Enrico Del Fante: you.

Potuz: So when we request a range, we expect to get the exact range. It would be fine if you don't reply to payloads. And then we get the payloads from another peer. The problem is when we get a peer that serves us inconsistent data, we downscore that peer. If a peer doesn't serve us anything, we don't downscore. We just say, okay, fine, we didn't get a reply. For example, you could have been, like, rate-limiting us. But if you do serve something that is not consistent, then we downscore you.

Enrico Del Fante: We'll take a look. But since, like, we are the only one, because you go offline, then Lighthouse is not there, Lodestar has a similar problem, and everything is not working. So why only Teku has that?

Potuz: No, no, I don't know. I only looked briefly at the logs, and I found this peer ID that was TechU. I suspect that Lodestar has the same problem, because neither Lighthouse nor Prysm is able to get ranges, so I suspect that both of you guys are serving as the wrong range.

Enrico Del Fante: Might be, we need to double-check everything there.

Parithosh Jayanthi: Okay, I guess the place for this discussion would then be the ePBS channel? Yeah, please let Barnabus know if there's something to roll out. Anything else for Glamster and DevNet 3?

Enrico Del Fante: I think we have also a bug, in some cases when we sell Build. the bid, and we understood what was the problem, what is in our backlog to fix. It's… I don't think it's not, It's a big issue anyway, because it's not happening that often, but still something we need to fix.

Parithosh Jayanthi: Okay, so if possible, we'd still try to recover DevNet 3, and if not, yeah, I guess Barnabas would coordinate launching DevNet 4. There's a bunch of… there's a few open, PRs I wanted to discuss today. The first one's, gonna be raising the min builder withdrawability delay to 8192 epochs. This is, I'm guessing, in… yeah, it's for making the… making it more expensive for an attacker to spam new builder deposits. Is there any… Objection to this PR? Or is it a unanimous decision already?

Justin Traglia: I'm not sure if it's unanimous, but I think we should hold off. Until we do more testing, just for the… The stuff they were trying to test last week to see if, just extending the MIN withdrawal delay is an appropriate, solution. Or if we need to implement the queued, approach.

Parithosh Jayanthi: Okay, and is the testing there mostly just spamming deposits and checking the amount of verification time, or is there specific other tests being conducted?

Justin Traglia: I mean, yeah, pretty much. Yeah, see how the network handles spammed deposits for, like, new builders. Cotus.

Parithosh Jayanthi: Yeah, photos?

Potuz: I don't see how the queue itself even solves the problem. The part of the queue that sort of, like, might alleviate the problem is the fact that we're also capping, not only putting a queue, but the queue itself, I don't see that it's… it doesn't change anything in regards to deposits.

Justin Traglia: I mean, if there's something that would allow us to queue the signature verifications. It would solve the issue, but then it opens up other issues.

Potuz: It's… it doesn't, right? So if we still have to verify, like. the same limits as today, like 8,000 deposits per slot, and then we just need to verify 32 of those on a… on an epoch transition, then we're still broken. So the thing that the queue allows us is to actually cap it. And then the cat brings with other issues. But it's not the queue that solves it, the problem is the cat.

Justin Traglia: I agree, yeah. But why is it still broken? I don't get that part.

Potuz: Well, if we do put a cap, then it's a different issue. But it's not the cue. The point is that it's the cap. And I agree with what Misha is saying, that the queue allows us to put a cap, correct. But then… then we need to discuss what are all of the problems that come with having a cap itself.

Justin Traglia: I agree with you, there would be other problems. From a cap as well. we should try to figure out to see if, like, the… current approach of optimizing and increasing the men withdrawal delay is an appropriate solution. And if it's… if for whatever reason that's not, then we can evaluate the queued approach. Oh my god.

Parithosh Jayanthi: Michael?

Mikhail Kalinin: Yeah, thank you. I'm very curious and keen to see, and hear from other CL devs, what do they think about Potentially verifying thousands of signatures, in one slot. And, yeah, because we haven't seen from… we haven't heard from… from… Others on that matter.

Pawan Dhananjay: I did a small benchmark on Lighthouse last week, and I saw similar numbers to what Terence was posting for verifying the signatures.

Parithosh Jayanthi: Could you reiterate what those numbers look like? At what deposit number are we starting to have issues with processing?

Pawan Dhananjay: I think, for 8192 signatures, like, if all of them were valid and we could batch them, on my, M1 MacBook, it took, like, 700 milliseconds or something like that, and as you added more, invalid signatures, it, went up to, like, 1 point something seconds, so I think that is some… that is similar to what Terence was seeing. I, I, like, I did not, get the… benchmark, fully validated, that's why I didn't post it on the channels. I can, do the proper validation today and post it if I'm seeing, actually, similar numbers, but I think it is correct.

Justin Traglia: And, these were for new builder deposits. Just double checking.

Pawan Dhananjay: Sorry, could you say that again?

Justin Traglia: And just to double check, these were for, like, new builders? Like, not existing top-ups or whatever. Okay, perfect.

Dustin Brody: There is a more general concern here about the scaling with the gas limit as well, so… For the most part, on the CL side, what we have had, and this is potentially going to change, obviously, with 7688, let's say, but what we have had is the limits defined on the CL side. So… And… and that's regardless of gas limit. Like, there's… they're separate things. Now, there's good arguments, let's say, to have them, in fact, not be separate things, and I wanted to… conceptually, I… I get that point, but it also means that now, if people are going to talk about Let's say 200 as a target, but obviously increasing from there, from Amsterdam. Now the question is, well, okay, people are talking about 700 milliseconds, does that become…

One, you know, one and a half seconds, two seconds plus, and especially with 6-second slots being kind of on the horizon here as something there's already a strong push for. So, I think we should still be a little bit, at least cognizant of the time it takes to do these signatures, and not just effectively treat them as quasi-free.

Parithosh Jayanthi: Okay, so I guess the next step for this one, as Justin said, is we continue benchmarking, we have a look at what the numbers actually look like, validate them, and then we take it from there. Yeah, photos?

Potuz: I think we should probably have an actual number of what is the cost, at least an estimation, of, like, raising this attack. like, we do anything else. We typically benchmark in terms of gas. Unfortunately, this is not the situation, because it's not that it's consuming gas, it's consuming compute time on the CL side, but it also comes with a cost. It comes with a cost in money, and this depends on the withdrawability delay. So we should have an… someone computing the numbers of, this is the cost at a reasonable, at a reasonable rate limit on, like, getting interest rates. This would be the cost if it takes you 2 months to get out, and this would be, like, the cost of maintaining such an attack.

So that we can actually have some actual hard numbers to be talking about.

Justin Traglia: The PR I provided did have some, napkin math. I think it was, like, $50,000 over the course of 2 months at 3% interest rate. So that's…

Potuz: For a cheap attack, then.

Justin Traglia: Well, that's just the interest, but yeah. And that's, sorry, that's per slot. So if you make… If you made, 5 slots with 8,000 one-eighth deposits, that would be $250,000. For 5 seconds.

Potuz: So, realistically, I mean, this… the cost is just really not that much, and realistically, the only risk is social slashing at that stage.

Parithosh Jayanthi: But that's also the interest, right? That's not the capital you would require as well.

Potuz: Well, but that's the thing, the capital, it's just irrelevant if you can take it out, right? So these are valid signatures. So the question is.

Parithosh Jayanthi: Sure, yeah.

Potuz: would anyone be taking the risk that we might, slash them? Because it's easy to slash them, it's easy to fork away that ETH.

Parithosh Jayanthi: Okay, also, just as a side note, would, repricings actually make this any… make any difference to this attack? I guess not really, it'll just make the upfront capital more, but, you know, you still have the same cycle-through problem. Sorry, go ahead.

Maria Silva: And… Yeah, I was going to say that, Barnabas was asking about this, and I did a quick analysis on the current, validator deposit contract, so I'm assuming that the builder deposit contract won't be very different from that. And with the current numbers we have on repricings in terms of gas, it would only be a 40% increase in cost. So I don't think that would be too significant. I think the math that, Justin was showing on the actual Costs in terms of the deposit amounts are… are… is more relevant here. So, this is to say, I don't think the repricings will give a huge cap on What you can do there.

Parithosh Jayanthi: Okay, so I guess next step would then be try to quantify the costs, and then, get some validated numbers, and present it at ACDC. Would someone be able to work on these two topics?

Justin Traglia: I can.

Parithosh Jayanthi: Okay, perfect. Thank you very much. The next… sorry.

Barnabas Busa: One more quick question, Why is the signature verification so expensive, by the way? Would it not be possible for the depositor to… take care of this, and then, some later job could be done on the sales side. Same way as what we did for, submitting the proofs for the blobs, we… we just pushed the responsibility into the, Person that's gonna be submitting the blobs.

Parithosh Jayanthi: Yeah, photos.

Potuz: Yeah, so the problem is that if we had a different contract, the problem is that now we are using the same contract, and the same flow, and the same request. If we had a different contract and a different request that is sent for builders, then we could do the signature verification on the EVM itself, and then, effectively, we'd be capping the number of deposits by gas limit, which is what we should have probably done. But this comes with, like, significant drawbacks. Not only is the fact that we need a new deposit, a new request, a new engine call, and so forth, but but also the fact that we need to be careful about, like, some paths. For example, we don't verify signatures when it's a top-up.

Or… and this comes with UX things. I mean, some pools might use this phenomena, that we don't verify the signature when there's a top-up. You can argue that this doesn't exist for builders, so it might not be a big issue, but still, it's something to consider, again. And just adding too many unknown variables is… makes me unease. It would be much nicer if we could actually just handle this at the client level.

Barnabas Busa: Yeah, I do get that, but my question was, mainly, why is the verification take so long, and could the verification just take place,

Potuz: So the verification is because of the pairing. We need to do a… we need to do pay rings on the, on the, on the, on, on the elliptic curve, and that's, that's the costly thing. If we do this one by one, then it's a lot of pairings, and this is the problem. If we batch them, then we just do a lot of sums, that's not problematic, and then just one pairing, and this is fine. The problem is that if you get some random invalid signatures, then you need to, like, start, like, checking around to find out which one was the invalid one, and then you do a lot of pairings again. So it's easy to… it's easy to trigger in such a way that you cannot batch them.

Parithosh Jayanthi: Okay, I think we have the… I think that's most, most of the discussion points for this topic. I just wanted to bring up the consensus specs PR5224. Is that also just completely related to this topic, or is this a new topic?

Justin Traglia: Semi-related. So this is the original issue of if you… if an EL were to provide a CL, payload with more than the SSE limit, it would, fail to deserialize it, and be unable to propose. this PR effectively raises the SSZ limit to something that's, like, Practically unbounded. So, a million. Deposits per payload. So, I actually prefer just fixing it with a progressive list, but We haven't decided to include that in Hegota just yet.

Parithosh Jayanthi: Yeah, okay, I get what you mean by it's also partially related, because I guess this just blows up the verification cost again, right?

Justin Traglia: Yeah, sort of, yeah.

Parithosh Jayanthi: Okay, so… I'm assuming we also don't want to merge this right now, and we'll just… Leave it on the sidelines until we discuss the full topic. Like, a solution for the full topic.

Justin Traglia: I think we need to decide if we want this, like, temporary fix, or if we want to just, do the progressive list, stable container, whatever it's called. integrating that into Hegota.

Parithosh Jayanthi: I think it's a bit too early to decide if we want progressive containers, right? Because that's a… it's a much bigger topic to be adding.

Barnabas Busa: We have, multiple clients that have, Already implemented it, and they have signaled that they would be ready, so… I wouldn't shut that off as a possibility. I know that we need to focus on ePBS now, but we can just not trigger this bug on the devnet, and just assume that we're gonna fix it down the line, and then we should just fix it, I think, with the… Otherwise, we're gonna be adding something that we're gonna be removing later, and that just makes no sense.

Parithosh Jayanthi: Yeah, agreed. If the easy fix is just running the DevNet at 150 million gas instead of 200, then we should just do that, instead of changing the spec twice, or adding SSE right now.

Justin Traglia: I also agree. If others agree, I can just close the PR.

Dustin Brody: I, I, I agree.

Justin Traglia: Okay, I'll close the PR, and if, for whatever reason, we don't include stable containers in Hegota, I'll just reopen.

Parithosh Jayanthi: Yes, that sounds great. The next topic was an execution API PR from Tony. I'm just gonna post it here. Is Tony on the call?

Toni Wahrstätter: Yes, I am. This is… this is a small change, so, replacing one error code, then recently we moved from UINT64 to UINT32 for the block access index. So, most clients are already aware of that. We discussed it, I think, 2 weeks ago in the testing call. Then I also saw, I forgot, like, the block access list hash in the header. Clients have that already correct, but I forgot it in the specs, and this PR is also adding it. And the last thing is adding… a new RPC method to the debug namespace, namely debug getRawBlock access list, which returns the block access list in RLP encoded form. And those are the four changes. I saw Michael has already reviewed it. Thanks a lot, and also Ben approved it.

So I think we are ready to merge that one after the call.

Parithosh Jayanthi: Okay, perfect. If anyone else has an opinion on the execution API, please have a look, but yeah, otherwise, we would merge this in after the call. Okay. So the next item on the agenda is mainly, DevNet scoping, so we have to scope up, BAL DevNet 7, as well as Glamsterdam DevNet 3, sorry, Glamsterdam DevNet 4, or whatever version that takes, so the next iteration. maybe we want to do this as breakout rooms, just because the two are relatively separate. The only question is if the next Glamsterdam DevNet will use the same branches as Battle DevNet 7, or are you planning on pinning an older version? I think that question's for Barnabas.

Barnabas Busa: I think, we should just keep it, as is. But yeah, we should definitely talk about the gas limit issue, before we go into the breakouts.

Parithosh Jayanthi: Yeah, of course. Yeah, do you want to introduce the topic now?

Barnabas Busa: Sure. I'm not sure if I'm the best person to introduce it, but basically, the problem is that, Currently, if we have a guesstimate preference on the validator client, then the execution layer client will not know about it, and And vice versa, so if the EL… the local EL, is gonna say that, hey, this is the maximum gas limit you should be using, and the and the builder, proposes a bid in the P2P pool, then that, there's just no way for the ER to verify that. But, yeah, maybe someone can give a better overview than me.

Parithosh Jayanthi: Yeah, Nico, do you want to talk about it?

Nico Flaig: Yeah, so I linked the comment. So there was a original, or there was a previous PR from Jim, where we basically discussed if the CL should decide what guest limit to use during block production. So this was relevant because, currently, basically, you set the gas limit on the CL side, which is then used by builders, and… At the same time, you have to set it on the EL for local builds, but the dominant factor is really the CL gas limit, because 90% of blocks are from builders. So, we wanted to… Which is almost one and a half years ago now. And for claws. Also, first, this is good, because… it allows a user to only set this on the validator client, and currently they have to set it in two places. And the second reason why this is important for claws is because we need

the, if the CL wants to use a vanilla EL, then it needs to tell the EL what gas limit to use, if it uses that as a builder, because you need to adhere to the gas limit that the proposal wants. So the current static flag doesn't work anymore for this.

Parithosh Jayanthi: Yeah, Tony and then Bottus.

Toni Wahrstätter: Yeah, a quick question to Nico. Just from my understanding, the gas limit in the bid is the gas limit that the… from the preferences, and which is set in a client flag on the seal, right?

Nico Flaig: Oh, that's a second topic we should probably discuss, that.

Toni Wahrstätter: Oh, okay.

Nico Flaig: Yeah.

Toni Wahrstätter: Okay, then I confused that topic, no, sorry. Let's do that afterwards.

Nico Flaig: So mine is just about when you have to build a payload, in the payload attributes, if we should add the gas limiter.

Toni Wahrstätter: Okay, yeah, I get it. Yeah, and on this topic, I think the CO should then deprecate the gas limit flag, and accepted in the fork chess update from the CL. Because then we would never run into this issue.

Barnabas Busa: You mentioned DCL twice. Did you mean the EL to deprecate the flag?

Toni Wahrstätter: Not only the EL should deprecate it, and the CL would then be the source of truth for the gas limit, so validators would start their client with specifying the gas limit on the CL, On the validator client. And then we pass it from the CO to the EO, and when we build a block locally. this information would come from the seal. And not from the EL being… using any flag.

Barnabas Busa: Yeah, I completely agree. I'm really curious about what the others think of this, though.

Parithosh Jayanthi: Yeah, are there any yells in disagreement there? I mean, conceptually, it kind of makes sense the block is being made by the validator, so the validator should be deciding what the gas limit is. Yeah, Daniel?

Daniel Lehrner: Well, just, just to, just, just to verify, I mean, we have this rule that, block gas limit can only be changed, 1 divided by 1024. I mean, the validators do exactly the same, no? I mean, the… Yep.

Parithosh Jayanthi: assume that… I'm assuming that that is not being changed, yes.

Daniel Lehrner: Okay, because, I mean, that would be consensus-breaking, I mean, this we will need to change. Otherwise, I think we are fine.

Potuz: Yeah, it's just for the minor. The proposed change is just for building the payload, and not the validation of the payload. Validation would still be up to the EL.

Daniel Lehrner: Okay.

Parithosh Jayanthi: So it says that earlier, your EL would have either a gas limit baked in, or a flag, and instead of having a flag or a baked-in gas limit, you would rely on the validator to tell you.

Daniel Lehrner: Okay. Yeah, I think then it makes… so, I mean, I can only speak for Besso, but I think it makes sense, yeah. to do that.

Parithosh Jayanthi: Or do we have Wrath, Aetrax, Aragon, anyone?

Barnabas Busa: Who's gonna do the calculation for the actual gas limit used?

Marius van der Wijden: So I think the way it should work is we get the target gas limit, and if we are significantly below it, we… We increase by 1… 2024. And, if above it, then… the last block gas limit by that much. So, it's… yeah, it sets our target, it doesn't set the gas limit for the next block.

Parithosh Jayanthi: Exactly, but that's how this works today as well, right?

Marius van der Wijden: Yeah, yeah, I'm just saying, like, this, like, we are not just setting… blindly setting this, we are using this to adjust Yes. The previous.

Parithosh Jayanthi: airporters.

Potuz: Yeah, so the two topics are intertwined. I agree with Marius, and I think all of us in the CL, we wanted this to be the case, that proposal preferences set the target gas limit, so that the user only specifies its target. And… then on FCU, we should send this target to the miner, and then the EL would just reply back, eventually constructing a payload with the actual gas limit that was used. Then, on the CL side, we have this other problem, which is how do we validate bids coming from the builder? And they are specifying a gas limit in their bids, and do we want this gas limit to be The one that the proposer offered as target, or we want this gas limit to be the actual gas limit that the payload, constructed.

I think these two topics are intertwined. We can defer this latter discussion for the ePBS section, or we can have it now here. And I don't know if the EL devs want to have this discussion here.

Parithosh Jayanthi: I think it's kind of worth having here, purely because it would change EL logic slightly. So let's just do it, in the group. Even if it's only tangentially related to them.

Marius van der Wijden: Yeah, like, I didn't really get it then. So the idea is that you get some bits with a gas limit, and you don't know if this is a good gas limit. Then you need to compute the 10… 1… 10-24th rule, on the CL as well, from the previous head. Otherwise, we will just reject later on when we evaluate it.

Potuz: Right, so there are two options. My idea would be that the user, as a user of the node, the node operator, would want to only specify a target. And then, when we send proposal preferences, these proposal preferences should indicate the target gas limit. what is… what the user is specifying, what… what we want this cast limit to be. Not… not block by block, but just the target. Now, we should accept bits, and now here's the question, do we want to take the bid with the target gas limit, or do we want to take the bid with just, the actual gas limit? I always worked under the assumption that the bid was just from the builder saying, I am honoring your target gas limit that was specified in the proposal preferences.

And then both the CL and the EL would make the check that the gas limit was compatible with the previous block, that would be on the EL side, that's the consensus part of the EL side, and the CL should do the computation that the Actual pay gas limit is compatible with the target gas limit that was specified.

Parithosh Jayanthi: Yeah, that makes sense to me. Ben… Ben and then Enrico?

Ben Adams: Shouldn't the builder hit the… go for the block gas limit? That's currently valid, and then there… Target is whether to decrease or increase it. By the fraction. Not… I set a gas limit of… a target gas limit of 100, and then I only want transactions that fill 100.

Potuz: I didn't understand, Ben, could you repeat?

Ben Adams: From what you said, it sounded like the builder should respect your gas limit, but the… that you're… the gas limit you're requesting. But the builder should respect the… the block's gas limit. And then use your target as a signal whether to go up or down. No.

Potuz: Exactly, so I want the builder to respect what is my signaling to whether to go up or down. So, he should be sending bids, saying, I am respecting the proposal preference of whether we want to go up or down. But not exactly saying what is the actual gas limit that the payload had. So we can actually check later if the payload that was revealed is compatible itself with the gas limit that we proposed, with the gas target that we proposed.

Parithosh Jayanthi: let's assume that the current gas limit is $50 million, and then I restart my validator, CL, whatever, with a new gas limit of $100 million, and I'm the next proposer. The bids that I receive will be for 100 million, and then the payload that is actually revealed will be computed based on the 1 over 1024th rule, right?

Potuz: Exactly, and then the EL can verify that the gas limit actually did increase by just what it was allowed, and the CL would verify that it increased.

Parithosh Jayanthi: Okay. Enrico?

Enrico Del Fante: Yeah, we're just echoing what Podo says. We always had, reasoning about only target, and the only moment in which we have to deal with the actual gas limit is when we do the check after the block has been proposed, so… whatever is, the proposer thing, or proposer preference, whatever channel we want, we only think about target, which makes sense, and, definitely. Makes everything much simpler, and actually, we have to not We have… we cannot change… we… we… we won't change anything if we… if we do, let's say.

Parithosh Jayanthi: We're also just separating the concerns. The CL only cares about the target, and if the proposal preference is being respected, the EL is the one that cares about the block consensus logic.

Enrico Del Fante: Exactly.

Parithosh Jayanthi: Tony, and then Tony Barnabas Barat.

Toni Wahrstätter: Yeah, I think this is fine. The only question I had is also continuing from your example, Perry. Like, is the proposal preferences updated every time I set a new gas limit, such that builders are never using the wrong one?

Potuz: Yeah, we send them a block, an epoch in advance when we find out that we are a proposer.

Toni Wahrstätter: Okay.

Potuz: We just pick it up from the configuration file, or whatever it is, and we send it.

Toni Wahrstätter: But what happens if I update my gas limit, within the epoch, and then I'm the proposer? In this case, I would just reject all bits, right?

Potuz: If you updated your gas limit after sending the proposal preferences, if you were so unlucky as to restart your validator right after, sending your proposal preferences, and you knew that you were proposing. Most probably, you will send another proposal preferences, and I suspect that we're going to not gossip those, because we've already seen that. I mean, it's not specified, what happens on changes on the proposal preferences, but I think we just, like, reject now. We don't gossip proposal preferences that we have already seen.

Toni Wahrstätter: Okay. Yeah, I think the risk is low here. It's just that this is then a very strict rule, that I would just reject all bits that Don't have my latest preference, adhered. But I think it's fine.

Potuz: But your beacon node, if you just restarted the validator client, the beacon node is the one that is in charge of this, and the beacon node should have cached, just like every other beacon node, the proposal preference that you sent. So the beacon node will just send you to sign a bit that is compatible with your previous proposal preferences.

Toni Wahrstätter: Makes sense, okay, yeah, sounds good.

Ben Adams: But the EO would reject that.

Potuz: No, the yield would be fine. As long as the payload… as long as the payload that is revealed comes with the right gas limit, compatible with the previous block, the yield should be fine. The consensus on the yields should not change by this.

Ben Adams: Yeah, but you're passing in… the CL's passing in the limit that it expects, and… so if you were saying, I want higher. And that was registered. And then you restart and say you want lower. then the gas limit's gonna go up, the EL's gonna get the CL's message, then go lower. And it will reject.

Potuz: No, no, so the EL validation shouldn't change. The only thing that would change by this gas limit that the CL is sending the EL on four-choice update would be just to construct the block. So when, when, when we send FCU, to construct the local block, so that we compare with the external bits. So this would be just one extra bit that we're gonna get from our own EL. And then the EL as a builder would get also the proposal preference that, that the validator sent. It should be just like any other builder.

Ben Adams: L's not validating the proposals, but…

Potuz: Exactly. So we… I want this separation of concerns so that… that it's actually what… but at least in my mind, it's like it is. The CL should be in charge of checking that the proposer, the validator side, the consensus side, is compatible with what the user is asking, and the EL should be concerned with checking that the EL consensus is passing. And Marius, the only change that you need to… so you're asking what you need to change? Nothing. The only thing that you need to change is that when you're building a block. you're getting an FCU and this… with payload attributes, and these payload attributes will send you the gas target, instead of you taking it from a flag that your user is sending to your node. So forget about that flag, and just get it from FCU with payload attributes.

I think it should be easy from the L, and I was hoping that this was more like a philosophical discussion of who should be driving more than a technical one.

Enrico Del Fante: It's already happening right now, because… CL are sending proposal preference, so it's just making everything more consistent.

Ben Adams: Well, not for local building, but I mean, the EL underbuilds the blocks anyway, so that's not really matter.

Enrico Del Fante: Yeah, that becomes consistent, essentially.

Parithosh Jayanthi: Bar numbers?

Barnabas Busa: I would seriously like to propose the idea to just remove the gas limit from the bid, and from the proposal preferences, and make it a BPO-like configurable limit on the EL and the CL side, so that if you want to change the gas limit, we would do it at a BPO4. It would make the protocol significantly, easier. And, like, this is such a small thing that we've been discussing over and over again, I just feel like it's gonna make our life a lot easier, and a lot more safe. Ethereum's just gonna be a… Loch Nore Safe Protocol, if, if you have this.

Parithosh Jayanthi: Pk had a nice counterpoint, though. Gas limits can be coordinated, reduced in times of attacks. If we tie it strictly to BPOs, then you need a fork to Thwart the attack.

Barnabas Busa: Yeah, I mean, same for, if the block count is too high, then it's still in the fork to remove it, to lower it.

Enrico Del Fante: I believe we should always be… leave the opportunity to have an override. Because anyway, it's a user can be changed by the user. Theoretically. So a user should be able, anyway, to override if he wants to.

Parithosh Jayanthi: Yeah, I think you're gonna need at least an EIP to convince people and discuss on, but yeah, I don't think it would be as simple as that. It might be a contentious decision. But yeah, please bring it up with an EIP and potentially an ACDE as well. Yep, Baron?

Bharath Vedartham: Yeah, hello. I just wanna, just, like, summarize, like, my understanding of the gas limit check on the bid, like… so I think what we're agreeing upon is that the bid… the gas limit in the execution payload bid, and in the payload envelope. Is the target gas limit. And when we send the payload to the EL via the engine API, the EL is responsible for ensuring that the calculated gas limit is accurate, and if it's not, the block gets, like, rejected from the end. I'm just glad of him. Because the spec today, like, in the, consensus spec, we specify that, the gas limit in the bid, should be, the… should be the gas limit to the constructed payload, which is the calculated gas limit. So, like, yeah, if we agree upon that, we only want to set the target gas limit in the bid and the envelope, I can, like, we can make a change in the,

like, spec to just, like, note that. So, just wanted to clarify my understanding.

Parithosh Jayanthi: Yeah, I assume Portos wants to answer this one?

Potuz: Yeah, I wanted to give an example. So, yeah, so if it's specified now that the bid should be the actual payload's gas limit, that's just wrong. That's not a check that we should do. I believe that the natural check is the following. The proposer sends, the proposer preferences, saying, I want a gas limit of 200 million. The current gas limit is, say, 300 million. Okay? Now, the builder should be sending bids saying, I will allow… I would send this gas li- would honor the 200 million gas limit. So that's a signal that the builder is saying… sending the right direction of the target. So now, we only accept bits for 200 millions, even though the current gas limit is 300 million. Now, the payload is revealed.

And let's suppose that the payload is revealed for 300 million plus a tiny bit, plus epsilon. We send this payload to the EL. The EL makes a validation with respect to 1559, rules, and the payload is valid. It increased, and it increased by a little bit. But the CL makes a validation against the target, and the payload is invalid, because the payload did not honor the target that the proposer wanted. The target was 200, the gas limit should have been lower than the 300 million. I hope this was clarifying enough. Nico was asking exactly the same question.

Bharath Vedartham: Yeah, I think that makes sense to me, yeah. So basically, the CL only cares about, like, the target, and… or about the… and the EL only… and the entire, like, calculated gas limit computation validation is on the EL. On the EL?

Potuz: It's the same validation as today, which is 50-59 rules, and the CL adds a validation against the proposal preferences.

Bharath Vedartham: Got it, got it. Yeah. Okay, that makes sense to me, like…

Marius van der Wijden: I have… I have a quick question. So in that scenario, I… we have 300 million block. I'm… my preference is 200 million. I send $200 million to the builder. The builder now returns me, $299,999,999. block? which is valid from this year, because it's below the $300 million, which is valid from the EL, because it's, Like, less than the 1… 10… one… One 1024th rule, but it's not really what a local builder would have done, because the local builder would have done I don't know, 298,000…

Potuz: Right, exactly, exactly subtracting the maximum that it should have subtracted.

Marius van der Wijden: Yes.

Potuz: And I think that the CL should take care of saying that this is invalid from the CL side. every CL has the numbers to check that this block did not satisfy the proposal preferences. We should enforce this at the consensus level. This is an easy check, also.

Parithosh Jayanthi: Yeah, Tony, and then Nico.

Toni Wahrstätter: Yeah, just to… just to summarize for me, so basically during block validation, if the gas limit is increased or decreased, that is all done fully by the CL, and the EL will only check that the 1 over 1024 rule was obeyed. So this is one thing, and then for block building, we can agree on deprecating the flag on the CO, on the EL, sorry, and the CO will pass the gas limit, the preferred gas limit, to the EL, but the EL should never store that, right? The EL will just, enforce the… the 1559 rule, and will never reject the block that, for example, goes into an opposite direction of the last fork chess update payload attributes.

Parithosh Jayanthi: Yeah, could we get a comment from other CLs about this? Seems like Porto's is in favor. Okay, what's the next step here? Is there a spec that has to be updated and a PR we can discuss this on, or how do we proceed? I think to Marius's earlier point, what is concretely changing from the EL and CL that we have to implement in the next DevNet, potentially?

Marius van der Wijden: a change to the payload parameters in the engine API. I think this is the only change. On the, on the EL.

Parithosh Jayanthi: Okay. Perfect. Photos, would you be able to make a PR for this?

Potuz: Can someone else do the engine API? I have… I have an allergy to APIs.

Toni Wahrstätter: I think Nico had an API, or at least, Nico, you posted an engine API change.

Potuz: Alright, probably Jim already had one.

Toni Wahrstätter: Yeah.

Nico Flaig: Yeah, but that one is probably outdated, but, yeah.

Potuz: I nominate Nico for this.

Justin Traglia: I also nominate Nico.

Parithosh Jayanthi: Nico, if you have some time this week, could you update it, and then, we can set aside some time on ACDC this week, and then merge it in latest by next week?

Nico Flaig: Yeah, I can look into that. But… so the other thing was with the validation, right? I'm still not convinced what Portis is saying, that the CL should do the EIP1559 calculation. Like, I know we have that in the code currently to check the header we get from the builder, but… It would be ideal if we can get rid of this code from the CL side, in my opinion, at least. And at minimum, we would need to change the CL spec, because currently the fork choice on execution payload has a strict validation against the payload gas limit. So, this is wrong if we go with that approach.

Potuz: So you'd suggest, Nico, that the EL does the target competition as well? And for this, we should send the target, on… on new pay… on notify new payload, right?

Nico Flaig: Yeah, exactly, that was my idea, yeah.

Potuz: Yeah, those are the two options, but then for that one, you're gonna need to get some buyers on the Yale side, I guess.

Nico Flaig: So there was one thing Barnabas brought up, is that this calculation might get more difficult with some EL EIP.

Barnabas Busa: Yeah, it didn't the truth.

Nico Flaig: So I think, from a decoupling point of view, it would be cleaner if the EL just does that. Because right now, this calculation… I'm not even sure where the EIP1559 is defined, other than in the EIP itself. I think that's where I implemented it in Lodestar, or where I got it from. So… Yeah, would be good if the EL can handle that too.

Toni Wahrstätter: So you want to send the target to the EL, and the EL would reject the block if the gas limit is still within the 1 over 1024 boundary, but, for example, it moves into the wrong direction.

Nico Flaig: Yeah, exactly. So in the example that we had earlier, we would just send the $200 million, and then the L would say, okay, it moved. In the wrong direction, or not enough in the right direction, then we would reject the payload.

Potuz: So the trade-off here is that the CL is doing a check that is of its concern, because the proposer is handled by themselves, but the computation itself is on EL data. And I kind of understand where Nico is coming from. I still believe that it would be much easier for everyone if we do this check and we don't even send the payload to the engine if we fail this check. So we do this check assuming that the gas limit is what it's been promised. And if the payload does not satisfy what the proposer is requesting, we don't even send the new payload to the engine. And if it does satisfy, then we send it to the engine, and then the engine would check 1559, and also that the gas limit that is written is the gas limit that actually was used. So we're sure that our previous computation was correct.

Bharath Vedartham: So then, just to clarify, like, we… we want to do the… So, yeah, okay, so we want to do the EIP529 check in the CL also, because I thought I was on the assumption that, let's say, like, the proposal preference had 200 million. Those preferences had gas limit of $200 million, like, the builder… the bid would set, like, a gas limit of $200 billion, regardless of, like. the, regardless of the actual gas limit. I was, like, a little confused there. But, like, you're saying that we will… in the bid and the envelope, the builder will set the gas limit, the actual, like, gas limit, and the the CL will verify based on, like, the parent

the parent block, whether it's… whether it's the correct update. Basically, the 1 over 1024 update.

Potuz: We could do that, but then it becomes slightly more complicated on bid validation.

Bharath Vedartham: It's an option to…

Potuz: to send the bid. It seems easier to me to send the bid just, like, we just check that it's equal to the proposal preferences.

Bharath Vedartham: Yeah, but in that case, you would run it… you would have the issue where you accept a bid with the wrong… with the right target gas limit in the bid, but potentially, like, a wrong gas limit in the payload. So you accept a bid, but the payload gets rejected.

Potuz: That's fine. From the proposal point of view, it's fine. The builder's going to pay anyways.

Bharath Vedartham: Yeah, I'm mixed.

Parithosh Jayanthi: Okay, so we'll be getting an API PR and potentially a gas limit change EIP suggestion from Barnabas, and then we can discuss both of these in future ACDs. Does that sound good?

Bharath Vedartham: I think we'll also need, like, a consensus spec PR for the gas limit check on the bid. Because today in the spec, we say bid.gasLimit equals proposal preferences. Gaslimit? I can raise a PR to… which, like, checks against the actual gas limit, and then, like, we can probably make a decision what we want to do. Yep.

Parithosh Jayanthi: That would be great, thank you. So one topic we didn't get to is, DevNet, speccing, so we're just going to decide to do that async, and if we're not able to do it async, it'll happen first thing on ACDC this week. That being said, thanks everyone for joining, and sorry for the overtime.

Andrew Ashikhmin: Thank you, bye-bye.

Pooja Ranjan: Thank you.

Toni Wahrstätter: everyone. Bye-bye.

Potuz: Everyone?

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