AllCoreDevs - Testing #066

|2026-01-19| Agenda: #1878| canonical JSON

Transcript

Parithosh Jayanthi:Okay, let's get started then. First item on the agenda is getting an update on block-level access for StevNets. Stefan, you have the floor, do you want to give us an update?

Stefan Starflinger:Yeah, sure. So, definite one.

Stefan Starflinger:was working pretty well. We got syncing fixed in most clients, which is really nice. And, we managed to run stable with EVM fuzzing and Uniswap trades as the workload.

Stefan Starflinger:The only thing we couldn't get done was the benchmarking part, with parallel I.O. and parallel execution, so that will be moved to, definite 2.

Stefan Starflinger:And in general, now we have to decide what we want to put into, Definite 2, and what we want to push for Definite 3.

Stefan Starflinger:I think that is a quick summary.

Parithosh Jayanthi:Awesome. Yeah, we have finalizing DevNet2 scope a bit later in this,

Parithosh Jayanthi:Actually, we can already continue with that.

Parithosh Jayanthi:Okay, let's… let's just continue with DevNet2 scope, then. Was there… I see Spencer has this, comment in the issue. Do we want to just go through the comment and solve all of the questions?

Parithosh Jayanthi:Eip7843. So the question is, do we push this to DevNet 3, or keep it on DevNet 2? This requires CL changes, and there's two open, PRs linked over there. Who has the most context on this?

Parithosh Jayanthi:Okay, looking at it, it mostly looks like engine API changes, are…

Parithosh Jayanthi:Stefan, do you have an idea how many CLs are ready with block-level access lists to begin with?

Stefan Starflinger:So the only CL we've been using is Lodestar.

Stefan Starflinger:Because there is some inconsistency between Prysm and Lodestar that we haven't been able to figure out.

Stefan Starflinger:And Lodestar has already merged the PR, for this change.

Stefan Starflinger:It hasn't been tested, but it seemed to be pretty small. I can share it in the chat.

Stefan Starflinger:In a second.

Stefan Starflinger:But I would generally prefer to keep it in, unless there is a reason not to. I don't think it's that much of a change.

Parithosh Jayanthi:Yeah, it doesn't look too big. Yeah, minimalist?

Barnabas:Yeah, so I reached out to Pawan last weekend, and he said that, he will have a DevNet2 ready branch, or Lighthouse, either today or tomorrow.

Parithosh Jayanthi:Okay, perfect. So, since this is mostly an engine API change, and Lodestar already has it, let's keep it in, and if there's any opposition, then let's take it out later, but for now, let's keep it in.

Parithosh Jayanthi:Sounds good.

Stefan Starflinger:Yep.

Parithosh Jayanthi:Okay, next item is EIP8024.

Parithosh Jayanthi:This is switch encoding to push postfix.

Parithosh Jayanthi:I'm posting the link there…

Parithosh Jayanthi:Has anyone already reviewed this PR? Will this be a big change? It looks like it's an EL change, so does… do any of the ELs have a preference?

Parithosh Jayanthi:How many do we have any of the EL devs here?

Parithosh Jayanthi:Fabio, do you maybe want to speak for Bezu? Or Lukash for Nethermind?

Łukasz Rozmej:Hmm, sir, what's the question?

Parithosh Jayanthi:So the question is, does a change to EIP8024?

Parithosh Jayanthi:And we want to know if they should be included in two DevNets.

Parithosh Jayanthi:2, or if she… we should delay to DevNet 3.

Parithosh Jayanthi:I don't see any…

Parithosh Jayanthi:Okay. I also see a comment on the PR itself that says, probably not going with this change, so, okay, maybe we just deny this change for now, and if it needs to go in, we can bring it up on ACD.

Parithosh Jayanthi:Okay.

Parithosh Jayanthi:The next, order of business is EIP7778, confirm alignment on specs, and this is from,

Parithosh Jayanthi:From Tony, so you have the floor, Tony?

Toni Wahrstätter:Yeah, I brought up this topic on the Execution Dev Discord, I will post the link to the message into the chat, and I wanted to clarify if we want to use the

Toni Wahrstätter:Gas used pre-refunds, or gas used after refunds for accounting.

Toni Wahrstätter:The cumulative gas used in the receipts.

Toni Wahrstätter:And Andrew brought up last time on ACD that Erigon prefers to use the gas used before the refunds, which means that the block gas accounting will be consistent with the gas accounting in the receipt.

Toni Wahrstätter:And I quickly talked with Felix from Geth, and he was also…

Toni Wahrstätter:Saying that this might be the cleanest solution to do.

Toni Wahrstätter:The thing is, this might also mean that we…

Toni Wahrstätter:might want to introduce a new field to the receipt. Basically, the gas spent.

Toni Wahrstätter:So this will be the gas used, by the transaction.

Toni Wahrstätter:Pre-refund.

Toni Wahrstätter:Sorry, post-refund. So this could be used to, populate the field gas used in the EVE getTransaction receipt.

Toni Wahrstätter:And now I'm wondering if other clients have an opinion on that. This is the way how it's currently spec'd. So in the specs, we recently changed it to having this new, field in the receipt.

Toni Wahrstätter:Because, yeah, as I said, this might be needed because gas use now has different meanings, depending on do we use it for block gas limit enforcement, or do we use it to communicate that info to the user?

Toni Wahrstätter:So, I'm wondering if anyone has an opinion on that, or if anyone is opposed to doing it that way.

Parithosh Jayanthi:Yeah, Ben?

Ben Adams:Yeah, so I think the cumulative gas use Needs to be the…

Ben Adams:The amount used by the block.

Ben Adams:Not the amount. So… pre-refund.

Ben Adams:But I do also think, in line with ETH transfers, and it's a log,

Ben Adams:We will need that extra field, saying how much

Ben Adams:was actually spent in gas for the transaction. So… post-refund.

Ben Adams:And we could, replace, like, Logs Bloom with it if we want.

Ben Adams:Rather than adding a new field.

Parithosh Jayanthi:So you'd be in favor of keeping it in the same format, as it is right now, right?

Ben Adams:The… the one proposed by the… as the change, yes. But… but I think we need a change to the receipts so that if you're trying to use the available data.

Ben Adams:To track how much… An account's balance has changed.

Ben Adams:And we need to include the post-refund. You know, how much did the account spend?

Toni Wahrstätter:Yeah, exactly. This is how it's specced right now.

Toni Wahrstätter:Yeah.

Ben Adams:Because we can't work out the, we can't do the… Jason or a PC, otherwise.

Ben Adams:Or…

Toni Wahrstätter:Yeah, exactly.

Ben Adams:also undermines, ETH transfers in Metalog, if we don't have… How much the account spent.

Toni Wahrstätter:Right.

Toni Wahrstätter:Is there also someone from Besu, just to… or… and from Rife? Because then… then it would be great if we get an opinion from all the clients on this.

Toni Wahrstätter:Also, if Gef has an official opinion.

Toni Wahrstätter:It'd be great to have that clarified today.

Parithosh Jayanthi:Yeah, I see Daniel from GETS, do you want to speak up?

Daniel Lehrner (Besu):I can speak for Besso. We have not really looked into the PR, so it seems…

Daniel Lehrner (Besu):I think we are fine with whatever is proposed.

Daniel Lehrner (Besu):I really don't have much details at the moment, but…

Daniel Lehrner (Besu):Neither… neither proposal seems to be a big problem for us, at least from the implementation side.

Toni Wahrstätter:Okay, great. Yeah, I think… I think it will still keep the… keep the scope, quite limited. The only thing is that clients have been using, cumulative gas to determine what is the gas used of a transaction when it comes to e-gat transaction receipt calls.

Toni Wahrstätter:And yeah, the change that is now needed is basically to keep the…

Toni Wahrstätter:Same behavior there that we have today.

Toni Wahrstätter:Yeah, if you haven't looked into it, please,

Toni Wahrstätter:just check it out and comment on the EV… on the execution dev, but I would then assume we go ahead, create the test cases, for this new

Toni Wahrstätter:format.

Toni Wahrstätter:And also already included.

Toni Wahrstätter:In this new, with those new changes in the second DevNet.

Parithosh Jayanthi:How much work or time do you think it'll be adding to DevNet2?

Toni Wahrstätter:I can't answer that, so from the specs and ERP side, it's done. It very much depends on how much work is it to add new fields to the receipt. I think that's the only thing.

Toni Wahrstätter:I don't really have insights into how much work this is at the client.

Parithosh Jayanthi:Okay, then I think I'd prefer moving it to DevNet 2, so we do it in the next DevNet, and bite the bullet, even if it takes a little bit longer.

Parithosh Jayanthi:Does that sound good for everyone?

Ben Adams:Move the change, or the EIP?

Parithosh Jayanthi:as in the EIP, as well as the change, is included in the scope of DevNet 2.

Parithosh Jayanthi:Okay.

Parithosh Jayanthi:Thank you. And the next one is proven merge spec changes for EIP7708.

Parithosh Jayanthi:I see Ben's been digging into this one. Do you want to give us some context, Ben?

Ben Adams:Oh, okay, yeah, so… This would be…

Ben Adams:Any non-zero transfer that's not included in… already in a different field?

Ben Adams:of ETH.

Ben Adams:So, for instance, paying gas,

Ben Adams:It's already included in the transaction, which is…

Ben Adams:why I said there's a little bit of conflict if we lose that information.

Ben Adams:Then we emit a… we emit an ETH transfer log.

Ben Adams:So that you can… you can build…

Ben Adams:The state of an account just from looking at logs, withdrawals.

Ben Adams:And transactions without having to, previously, I think you have to debug trace work out ETH transfers.

Parithosh Jayanthi:Okay, got it. Has everyone gotten a chance to look at this PR, or not yet?

Parithosh Jayanthi:Yeah, Spencer?

spencer-tb:Hey, yeah, I just, I guess…

spencer-tb:I linked it in the comment, just, so I think as the…

spencer-tb:PR aspect right now, and we're using… The forced…

spencer-tb:478… 4788, address, system address?

spencer-tb:I guess I just want to confirm that everyone's okay with using that address.

spencer-tb:in the PR,

spencer-tb:Yeah, and then if that's the case, then I guess we go with it. Also, I think initially this PR included

spencer-tb:few receipts and withdrawals as well, not just ETH transfers. So this…

spencer-tb:This PR… yeah, it's only for ETH transfers, and I believe ETAN moved a few receipts and withdrawals to a separate PR.

spencer-tb:Yeah, so if everyone's okay with that, then I guess we can just stick to that as the spec for DemNet 2.

Parithosh Jayanthi:But…

Ben Adams:on the… on the address specifically, an opinion that's not strongly held is, I'd prefer the address

Ben Adams:to be… zeros.

Ben Adams:Because it's not, it's not a…

Ben Adams:The one currently chosen is… this is the system.

Ben Adams:Whereas we're talking about ETH, the asset, which the zero address seems more appropriate for.

Ben Adams:Rather than the system.

Parithosh Jayanthi:I think there's a comment here explaining the three options, right?

Ben Adams:Yeah, so zero… system address, and… Eip788.

Parithosh Jayanthi:Got it.

Parithosh Jayanthi:Does… has any… Client team, et cetera, had a strong opinion over here?

spencer-tb:Maybe we stick to system address, and if we want to change it in the future, we can do that. Just for Definitely.

Parithosh Jayanthi:Yeah, I think that sounds reasonable. Let's stick to system address then, and we can still discuss on the PR, what to do.

Ben Adams:Could we have these PRs merged so that the… Correct.

Ben Adams:put emphasis on that, so that the,

Ben Adams:We can follow along with what's canonical.

Parithosh Jayanthi:Yep, sounds good. I'll write that down.

Parithosh Jayanthi:Okay.

Parithosh Jayanthi:The next point that, Spencer brought up was, a few EIPs PRs for visibility. Is there any PR here worth discussing, Spencer, or are you.

spencer-tb:You're located.

Parithosh Jayanthi:Just flag it in the comment.

spencer-tb:No discussion here, just wanted to flag it for visibility, yeah. Sorry.

Parithosh Jayanthi:Okay, that sounds good. And I guess, based on the decisions on the call, you guys would just merge in the required PRs, and we should be good to go?

Parithosh Jayanthi:Okay,

Parithosh Jayanthi:Yeah, that sounds good. The next topic on the agenda was, Amsterdam ETBS DevNet update. Do we have anything from the CL client teams? How close are we to the DevNet?

Parithosh Jayanthi:How are things looking?

Parithosh Jayanthi:Yeah, Jen?

Jen:Sorry, just before we move on, can we just reiterate what is the final definite 2 scope, and when are the timelines, and what is missing?

Parithosh Jayanthi:Got it. So for DevNet 2, we're gonna be, keeping 7843, along with both the changes that are, included in Spencer's comment. I'll link the comment, in chat here.

Parithosh Jayanthi:We're going to be, moving the 8024 discussion to later, so that it's not being included in DevNet2 scope, and would be included in DevNet 3 scope. 7778 is going to be, included along with Tony's changes, so it'll be merged.

Parithosh Jayanthi:Eip7708, we merge in the PR as is, and we still have to discuss the, the address, and that can be done later and updated in DevNet 3 if required.

Parithosh Jayanthi:As per our timeline, Stefan, did you have an idea on when you wanted DevNet 2 up and running?

Stefan Starflinger:I think it would be great if we could get all these PRs merged as quickly as possible. I think I will have everything ready to launch DevNet 2 around Wednesday, but I can set the Gloas fork for a little bit later.

Stefan Starflinger:So hopefully this week, we should be able to launch DevNet 2. It will be good to be ready by Wednesday… Thursday by the latest. That would be very nice.

Stefan Starflinger:But if, clients need more time, it would be great if they could reach out to me.

Parithosh Jayanthi:Okay, sounds good. If… and Clancy, the moment you have, images ready, then please just ping Stefan, and you can already have, local governments.

Parithosh Jayanthi:And Lucas has a question for 770H. Does it behave the same as each simulate? I would… Spencer, would you be able to take that question?

spencer-tb:Yeah, no, sorry, I'm not sure.

Parithosh Jayanthi:Okay, then we might have to discuss that later, Lukash.

Parithosh Jayanthi:I'm not sure if I have downside.

Parithosh Jayanthi:Okay, next item on the agenda was, Glamsterdam EPBS DevNet update, and Potuz has a comment. Do you want to speak up, Potos, or…

Parithosh Jayanthi:How do we want to do this?

Potuz:Oh, it's just that comment. We… it looks like the spec is finally frozen, at least in what regards to test vectors. Terence has, at least on Prysm, opened most of the, local processing of blocks.

Potuz:and… and all of the gossip, objects, we are reviewing them. We should merge those PRs in the next 2-3 days. Still, like, all of the periphery of the… of the…

Potuz:pull request needs to be developed. It will take more time to talk about Kurtosis runs, but at least the processing and the spec tests are going to be passing in the next 2-3 days.

Parithosh Jayanthi:Okay, do we have any other client teams? Cl teams… Phil, do you want to go for Lodestar?

Parithosh Jayanthi:Nico.

Matthew Keil:I apologize, can you ask that question? Oh, go ahead, Nico.

nflaig:So, we have a few PRs open for fork choice, gossip changes, and there's still some work to do for DevNet.

nflaig:But yeah, it's looking to get pretty complete now.

nflaig:But yeah, we are still a bit far.

nflaig:I think for the definite itself.

Parithosh Jayanthi:Okay, Dustin, do you want to go for Nimbus?

Dustin:Sure, so we've had… For… for a while, the… We're up to date on…

Dustin:Alpha.1 specs, with, with a couple of…

Dustin:With the fork choice proposal boost quirk aside, we haven't updated for that, but…

Dustin:For, for all the, sort of, EPBS, let's say, specific things.

Dustin:The… Otherwise, I think we're… we're missing… We're missing block…

Dustin:Production, we're missing a couple of other things, I… yeah, it's not…

Dustin:We're, we're getting there, but yeah, I would say we're… well, what was the phrase? A bit… a bit far? No, I mean, yeah, we're not… we couldn't do it in the next…

Dustin:Or so, for sure. Yeah.

Parithosh Jayanthi:Okay, photos?

Potuz:Yeah, I wanted to reply to a question that Marius has asked about timings. I speak for myself, but I always suspected that the timings on the PBS were only going to be chosen

Potuz:much, much further down the line, when we actually get some testing on more than just a local DevNet, but a decentralized one, so that we can actually measure what are the tightests that we can make.

Potuz:In particular.

Potuz:At the station deadline, we would want to make it as soon as possible. There is a PR that Francesco opened to make the payload availability deadline variable, depending on the size of the payload, and it seems that that's going to be merged.

Potuz:that, that PR also adds a new constant, which is What is the minimum?

Potuz:time that, like, a zero-size payload should have, and that, I think, also should be decided after we decide the attestation deadline, the tightest as possible.

Potuz:And then there's the problem of when the PTC deadline would be, that that will depend, I think, on the severity of the free option problem.

Potuz:And the blob count that we hit to target on Gloas, of course.

Parithosh Jayanthi:Yeah, so for Francesco's PR and the variable PTC deadline, I think that's a much bigger topic, and probably more appropriate for ACDC later this week.

Parithosh Jayanthi:But yeah, I wanted to continue with, DevNet updates. Solius, do you want to go for, Grandine?

saulius:Okay, so… Mmm…

saulius:I think we are still missing some, some stuff, and I actually need to check, again with, Hanglang what is the very latest status, on,

saulius:on this, on QC PBAS implementation. So yeah, as far as I know, we are still missing something.

Parithosh Jayanthi:Okay, do we have anyone from TECU?

Parithosh Jayanthi:Yeah, Enrico?

Enrico Del Fante (tbenr):Yes?

Enrico Del Fante (tbenr):So we merged, the…

Enrico Del Fante (tbenr):franchise change to… related to the proposed boost change that recently has been updated. We are surpassing Alpha01 things, testing, and

Enrico Del Fante (tbenr):But there are still pending, PRs related to gossiper rules validations. It needs to be… Updated… And,

Enrico Del Fante (tbenr):And there is still some work to do around, storage side?

Enrico Del Fante (tbenr):and, what else?

Enrico Del Fante (tbenr):Give him one sec, but… Yes, we… there is still,

Enrico Del Fante (tbenr):there is an open PR, but should be completed, about the non-validating builder's change.

Enrico Del Fante (tbenr):But, yeah, I don't think we are that close to having a… a definite… Ready client.

Enrico Del Fante (tbenr):At the moment.

Parithosh Jayanthi:Okay, and what about Lighthouse? Do we have anyone from the Lighthouse team?

Parithosh Jayanthi:Okay,

Parithosh Jayanthi:If this is the case, then do we want to set a deadline for at least local kurtosis networks? Because I think at least having a timeline would help us scope the network and start working towards DevNet ID releases.

Parithosh Jayanthi:Do we want to aim for the end of the month for at least a kurtosis network with more than two clients?

Parithosh Jayanthi:Does that sound achievable? Prysm seems to be the farthest ahead, is that… Okay.

Parithosh Jayanthi:Photos says 11 days is not gonna be possible for Prysm.

Parithosh Jayanthi:What timeline would be reasonable for PRISM?

Parithosh Jayanthi:Or for, for the CLs in general.

Potuz:Yeah, I don't think Prysm is the farthest ahead.

Potuz:And also, don't know about timelines.

Matthew Keil:We also don't have an estimate on timelines, but it's… A few weeks, probably.

Parithosh Jayanthi:Okay.

Parithosh Jayanthi:Okay, I think we're definitely gonna have to decide at least scoping or some sort of thing for at least local devnets, because if it's gonna take a month to even have the first local DevNet, that's extremely long.

Parithosh Jayanthi:Especially because we still have changes coming in, and we haven't even started testing.

Parithosh Jayanthi:But yeah, we… I guess we'll parallelly start working on a testing roadmap and see where we can merge the two in.

Matthew Keil:So, I don't know if it's worth bringing up again, because I'm not sure, how things have been built, but if it's possible, where we can break the EPBS scope into pieces, I don't know, again, I know Potuz had, we had talked about this, and it's difficult, but if we could do, like, slot restructuring, and then do the…

Matthew Keil:some of the other scopes, in a second phase. Just a thought.

Parithosh Jayanthi:Yeah, maybe we can add this as an agenda item for Thursday's ACDC as well, because I do think ACD is gonna have opinions on at least some sort of timeline.

Parithosh Jayanthi:But yeah, I agree with Dustin, it might add more complexity than it's worth, so at least we have to discuss it and decide.

Potuz:It's kind of irrelevant for this, right? So there's no… there's no trustless payments on…

Potuz:on the DevNet. There's not even builders, there's not even external builders on the DevNet.

Potuz:It's just self-building for the DevNet.

Parithosh Jayanthi:Yeah, well, on the DevNet, you can have external builders if you want, but…

Potuz:No, we…

Parithosh Jayanthi:the need.

Potuz:we agreed.

Matthew Keil:No, I don't think we should.

Potuz:Yeah, we.

Parithosh Jayanthi:Yay, we don't have…

Potuz:There's not going to be any external builders, there's not going to be even a P2P broadcast of bids.

Parithosh Jayanthi:Okay.

Parithosh Jayanthi:That sounds good as scoping, for sure, yeah.

Matthew Keil:Yeah, and I don't necessarily know where to break it, I'm just thinking outside the box of a way in order to try to get it piece-a-meal. I just don't know from implementation specifics, like, it would be a challenge for us to do it, but I'm just kind of… who's your thought.

Parithosh Jayanthi:Yeah, I think we might need to also update the specs page with these caveats, but we can do that after the call.

Parithosh Jayanthi:Okay, just to summarize the DevNet discussion before we move on to the next topic then, for Glamsterdam, EIP78437778

Parithosh Jayanthi:7708 are included in DevNet 2, along with all of the changes proposed. EIP8024, the EIP is included in the DevNet.

Parithosh Jayanthi:Just that the changes are not being included in the DevNet as proposed. Just wanted to clarify that because I might have misspoken earlier, but yeah.

Parithosh Jayanthi:And for EPBS, we'll update the specs page and TBD on a date, but we should try to have at least a local version of the DevNet up and running so we can start testing, and then the testing teams will get together and start making testing plan for EPBS.

Parithosh Jayanthi:Any open questions for Glamsterdam?

Parithosh Jayanthi:Okay.

Parithosh Jayanthi:Then I would hand over to Anskar, because he wants to, continue the discussion from ACD last week on EIP8037.

Parithosh Jayanthi:You have the floor answer.

Ansgar Dietrichs:Perfect, can everyone hear me?

Ansgar Dietrichs:Yeah, well, I assume so. Yeah, so basically, we more or less finished glumpstump scoping on last ACDE. There was one last decision that we wanted to postpone to today, and that specifically is about, EIP 8037, so, our specific strategy for state growth in

Ansgar Dietrichs:Glamsterdam, and just to basically remind people, basically, the EIP, as it was proposed by the champions, on, Thursday, basically has two elements to it. One of them is this mechanism that, dynamically adjusts, the state growth pricing based on the gas limit, so that means that instead of a

Ansgar Dietrichs:one time, probably pretty, severe, repricing right at the, the hard fork. It basically just…

Ansgar Dietrichs:grows together with the gas limit, so if we over time increase the gas limit, there would be… the state growth operations would become more and more expensive over time. So that's the element one, this dynamic pricing, and then the element two is this, separate metering for, state growth gas, and that specifically, was meant to address this.

Ansgar Dietrichs:The issue of contract deployments, and the maximum per transaction.

Ansgar Dietrichs:gas cap. So those are the two elements, the, the dynamic, pricing based on the gas limit, and the, the separate metering for contract, for, for, for, to enable, large contract, deployments. Yeah, and ideally we would…

Ansgar Dietrichs:then make the decision today on whether to include, CFI, the EIP, in that form, or consider alternative forms.

Ansgar Dietrichs:I was thinking to start by handing over to Marius to basically give an update of the discussions that were happening,

Ansgar Dietrichs:Over the last few days, Marius, are you on the call?

Ansgar Dietrichs:Maris?

Ansgar Dietrichs:What?

Ansgar Dietrichs:I do see Marys on the call.

Mario Vega:Maurice, we cannot hear you. Maybe, your microphone's not working.

Ansgar Dietrichs:We can hear you now.

Ansgar Dietrichs:You can go ahead.

Marius van der Wijden:Okay.

Marius van der Wijden:Yeah, so, sorry about that. I, over the weekend, I wrote an explainer about 8037, and why we think it's the best solution, for the network right now in order to increase the gas limit.

Marius van der Wijden:Yeah, I don't know if the problem with my microphone is,

Marius van der Wijden:because of my microphone, or because the person… because it's a person sitting in front of the computer. But anyway,

Marius van der Wijden:Yes, so if there are any questions, I'm happy to answer, questions about the… about the EIP. I think we feel very strongly that, this is necessary to ship in Glamsterdam, otherwise we cannot

Marius van der Wijden:Significantly, increased the gas limit.

Marius van der Wijden:with the… with Bells and EPBS and… and the repricings.

Ansgar Dietrichs:Yes, we can go through the list. Amazing.

Ameziane Hamlat:Yeah.

Ameziane Hamlat:So I raised a few questions on Discord. So for me, as it is today, EIP8037, for me, there is, like, some kind of regression compared to, to Fusaka.

Ameziane Hamlat:Because, with EIP 7825, we have this limit, of 16.7,

Ameziane Hamlat:Media and gas, so we can have multiple transactions per block.

Ameziane Hamlat:And, with this EIP, we can have, much bigger transaction, especially if it has, create, like, like, create state,

Ameziane Hamlat:inside.

Ameziane Hamlat:And so we can go, basically up to the whole block with, with one transaction.

Ameziane Hamlat:So, I understand that we are metering separately, compute and, and state creation, state growth.

Ameziane Hamlat:And we still have, like, for this state, growth,

Ameziane Hamlat:op codes, especially for us as a store, we still have, like, this compute part that counts for 16.7 million, but still, at the end.

Ameziane Hamlat:Before, we could have multiple transactions, in one block.

Ameziane Hamlat:And today, in the future, we would have only one transaction.

Ameziane Hamlat:This may be…

Ameziane Hamlat:will not the worst case. Actually, I am… I don't know, because we need to, maybe, to benchmark it.

Ameziane Hamlat:But for me, this is, like, a big change in… especially with

Ameziane Hamlat:For, for block access lists in the future.

Ameziane Hamlat:So this is, like, the main concern I have. My understanding is that we have… we have, like,

Ameziane Hamlat:this different metering to handle that, contract deployment, use case, with 20, 24 kilobytes. So, so for that, 18 million gas,

Ameziane Hamlat:18 million gas limit, transaction limit, either on the state, for example. We could imagine another gas… transaction gas limit on the state, creation part, that… that would

Ameziane Hamlat:mitigate, that would mitigate this issue. So I wonder why we… we want to, like, we don't want to cap state, state transactions.

Marius van der Wijden:Yes, that's, that's a good point. And, this is, and, Anska, said in the chat, any single transaction action can never be heavier to execute than the 60 million gas limit.

Marius van der Wijden:This is true, however, it is also true that now a transaction could…

Marius van der Wijden:Again, as before Fusaka consumed the entire block, and spent most of the block on, on state creation, and the, the result would be a single transaction that executes 16 million gas.

Marius van der Wijden:on, on compute, and, everything else on state creation. So yes, but…

Marius van der Wijden:Still, we would… we would be in the 16… 16 million…

Marius van der Wijden:Still, we would limit this transaction by 60 million gas,

Marius van der Wijden:Limit, and this is a very…

Marius van der Wijden:Weird corner case where someone is willing to deploy… willing to pay for a lot of gas in order to deploy, or in order to create a lot of state.

Marius van der Wijden:And, that is… there's nothing different about this.

Marius van der Wijden:Practically than, someone right now paying a lot of gas for 5 or 6 transactions to create a lot of state.

Marius van der Wijden:So… We can… We can, in theory, also think about adding a…

Marius van der Wijden:So basically what this EAP also does is remove the transaction gas limit cap and move it into the EVM.

Marius van der Wijden:And we can, we can think about reinstating that, in order to, in order to limit the amount of state creation that a single transaction, can do. That would, that would be possible. The problem there would be to…

Marius van der Wijden:what do we limit it? Like, we could limit it to 30 million gas, which would mean… which would allow, in the worst case, two transactions in the current block gas limit. The problem is if we 10x the…

Marius van der Wijden:the… the…

Marius van der Wijden:the gas limit again, then we would, then we would run into this issue again that we wouldn't be able to deploy big contracts within the 30 million gas, gas limit. So, a solution for that would be to,

Marius van der Wijden:To also adjust the gas limit

Marius van der Wijden:the… the allowed gas limit per transaction, in tandem with the block gas limit.

Marius van der Wijden:So we could do something like, at 60 million gas, you can have, have a transaction that costs 20 million gas at 100, 120 million

Marius van der Wijden:Yes, block gas limit, you can have transactions that have

Marius van der Wijden:I don't know, I cannot compute 40 million gas per transaction.

Marius van der Wijden:So, yes, those… can,

Marius van der Wijden:Yes, those would be, solutions to this, to this, to this

Marius van der Wijden:problem, but again, I don't really think it's a problem, because, in the worst case, you will only be able to execute one single transaction, and that will run in exactly 16MGAS, and so the…

Marius van der Wijden:the worst case… this will be significantly better than the worst case compute operations, and so there's no dose risk attached to it.

Ansgar Dietrichs:Ben?

Ben Adams:Yeah, following up on that, it does… it will create…

Ben Adams:weird corner cases, for instance, where I'm buying a token that's new to me, new to my account.

Ben Adams:That will cause state creation in New Balance.

Ben Adams:I could be forced out of being included in the next block, because all the state has been used up.

Ben Adams:Whereas somebody who's doing a swap Of that same token, but they already have it.

Ben Adams:Therefore there's… there's no additional state costs. They will get included in the box, so there's… those weird corner cases.

Ben Adams:Saying that, I'm… And for… it does solve problems, so… I think on…

Ben Adams:In aggregate, it's… it's a net positive EIP.

Ansgar Dietrichs:Yeah, and I mean, from my side, I will say that normally, I do think there's, like, some of these small details

Ansgar Dietrichs:that I do feel like…

Ansgar Dietrichs:would benefit from some further attention, just to figure out all these specific edge cases. Normally, there would be an argument for delaying the decision a bit more, but in this case, we just, you know, we just really need to get… make the decision. I personally think it would be fine to…

Ansgar Dietrichs:have an EP like this, in case we end up agreeing that this is the best version of it, to just CFI it now, and keep iterating on it, and so then if, say, by a week, two weeks from now, the shape it's in is not…

Ansgar Dietrichs:convincing for people. We can revisit this, potentially have a simpler version.

Ansgar Dietrichs:I think, I think that's reasonable, it has a lot of attention right now, a lot of people that keep iterating on it, so I personally, think that's fine.

Ansgar Dietrichs:So for today, I think my main question is basically whether people currently see the EIP as proposed as the best… the best candidate version, at least. So that we can CFI it, or whether people would basically…

Ansgar Dietrichs:Have a preference for swapping it out today for a, A simpler version.

Ansgar Dietrichs:Oh, yeah.

mhaas.eth:can you guys hear me?

Ansgar Dietrichs:Yes.

mhaas.eth:Yeah, thank you. Hi, I'm Marcus. I just wanted to say that I am actually pro the EIP8037, as it stands, and,

mhaas.eth:I honestly think that…

mhaas.eth:there was some questions regarding, developer UX, and I just want to say that as long as the tooling just supports this EIP, which shouldn't be that difficult.

mhaas.eth:I don't think it would complicate things any further.

Ansgar Dietrichs:Andrew?

Andrew Ashikhmin:Yeah, I think it's fine to CFI this EIP, but, I would be cautious about the dynamic pricing.

Andrew Ashikhmin:I think, it might violate some assumptions of, smart contracts, existing ones, and, also, like, the, smart contracts devs,

Andrew Ashikhmin:like, view, or picture. So I would actually go… I would fix this… the cost per state byte, and

Andrew Ashikhmin:Instead of linking it to the gas limit, and when we decide to raise the gas limit, we can have a mini hard fork to adjust the cost per statewide.

Ansgar Dietrichs:And just to clarify on that point, so would you prefer to see that change today, or would you, in principle, be…

Ansgar Dietrichs:okay with, ceifying the EIP today as is, and then revisit it, or, like, over the next…

Andrew Ashikhmin:You know, thoughts.

Ansgar Dietrichs:Two weeks or so revisiting this question.

Andrew Ashikhmin:Yeah, it's fine to revisit it later. I can Cify it now, I think.

Ben Adams:I don't think we can… I don't think we can,

Ben Adams:Do a mini hard book on gas prices, because they're… sorry, gas limit, because they're…

Ben Adams:At the moment, at least, they're independent, and we don't choose the gas limit.

Ben Adams:So, we couldn't…

Ben Adams:The validators put up the gas limit, and then go, right, we've got to do a mini hard fork.

Andrew Ashikhmin:Well, there's still coordination, like, it's… the EF analysis, recommended, gas limit, so I don't see it as a big problem. We… and we have something like the BPO mini hard forks can be perhaps configurable.

Andrew Ashikhmin:Anyway, I think this is something we can… Reiterate later.

Ansgar Dietrichs:Maria?

Maria Silva:Yes, I would… I would add on that point. I think we started to reach out to,

Maria Silva:app developers and the community itself, and I think in the following weeks, we'll continue to do that to really understand the potential issues with these dynamic costs. I think if we figure out that there's no issues.

Maria Silva:There, I don't see a reason why not doing it this way, because it seems…

Maria Silva:Much cleaner than doing a fork every time we need to increase the…

Maria Silva:the gas limits. But so… so yeah, we'll… we'll work on understanding better the issues, and if, if we find that the majority of the… of the community thinks it's… it's… it's okay, then, would that, make sense to you, Andrew, to just keep as is?

Andrew Ashikhmin:Yeah, yeah, sounds fine.

Andrew Ashikhmin:But, I mean, it just, of course, as you say, it's very important to clarify it with the…

Andrew Ashikhmin:Smart contract dev community, yeah.

Maria Silva:Great, will do.

Ansgar Dietrichs:Yeah, and then, one question that I had also posted in chat just now, if you want to leave a comment there or something, like, it seems like, at least right now, we're trending towards a CFI decision, but at the same time, also, people are… still have some questions or aspects that really need to be double-checked.

Ansgar Dietrichs:I think there's been very active discussion already on the Discord. My question would just be, is it sufficient to just say that, like, in between the next calls, we are basically… we will have an async, iteration on this, or would people also maybe prefer,

Ansgar Dietrichs:Want to have a breakout call scheduled or something, so it's… in addition to the async collaboration.

Ansgar Dietrichs:But I guess we… that can be a separate, decision.

Marius van der Wijden:I'm, I'm, I'm happy to, I'm happy to, to have a call. We will definitely iterate over some of the points that have been discussed today, internally within DEF, and, but also we can schedule a call and…

Marius van der Wijden:And share our progress, and make sure we are answering the right questions.

Ansgar Dietrichs:Yeah, then, I think for now, then, I would say it seems like the decision would be to CFI it. I'd give one more round of opportunity for people to protest.

Ansgar Dietrichs:But yeah, otherwise then, I think CFI-ing it, and then,

Ansgar Dietrichs:Making sure that there's good venues, both for just iterating in general, also iterating in a broader scope, and then, importantly, also, like, get feedback from app developers on topics like the disruptiveness of this dynamic mechanism, these kind of things.

Ansgar Dietrichs:But we can… we can do all of this async.

Ansgar Dietrichs:Yeah, so anyone, anyone who would be opposed to a CFI today?

Ansgar Dietrichs:Okay, then we can CFI 8037, and with that, we really, I think, have a finalized Gram Slam CFI scope, at least. Let's see how many of them will end up making it to SFI, but this is really exciting. Thank you all very much, and thanks, Pari, for letting me…

Ansgar Dietrichs:Take some time today to get this to the finish line. Awesome.

Parithosh Jayanthi:So, thank you. I wanted to maybe continue quickly with the, with the last one or two items.

Parithosh Jayanthi:Bharat, do you want to introduce what you're doing? I don't think we have to go into too much detail, but maybe it's useful context for everyone.

Bharath:Yeah, yeah, for sure, I can keep it short. Just the idea is, like, with EPBS, we had conversations on,

Bharath:on trying to, like, deprecate them as both sidecar. So, the main question that…

Bharath:I wanted to bring up in this call is, what is the temperature check on that? What clients feel? Do they… because I understand their EPBS, the Glamsterdam folk definitely is quite complex, and will clients be able to prioritize this? And secondly.

Bharath:If we absorb most of my boost functionality into clients.

Bharath:I just wanna… there might be some value in specifying some aspects of it in the builder specs.

Bharath:on the consensus specs, but I think it's better to be in the builder specs. There's some sense of, like, okay, like, for example, like, like, how a client can… how a client receives a list of builders.

Bharath:Right? Like, in the sense… builders or relays, using them as interchangeable for now. Like, and what are the parameters you pass? Like, okay, like, each builder has their main bid, has their,

Bharath:Like, you know, like, like, has the bid boost, and etc, parameters like that, and…

Bharath:I generally see some value in standardizing that amongst clients and bringing into a specification, and I assume most of it will just be implementation details, like querying bits in parallel.

Bharath:And stuff like that. But yeah, these are main… the main questions.

Bharath:I had, number one is, like, what's a temperature check on defecating… absorbing MevBoost into clients for Glamsterdam? Secondly, how much of it do we want to specify? I guess the how much of it do we want to specify in the spec? We can take it offline, but I was just curious to understand,

Bharath:How, what client teams are thinking about, bringing in that boost functionality into the… absorbing that into clients for glamster?

Parithosh Jayanthi:Yeah, do CL teams wanna talk to that?

Bharath:Yeah, I think Dustin raised it, like, the… is this really a spec thing? Yeah, I agree, like, a majority of things, I think it would be an implementation thing, but I was just wondering, like, is there some aspects we'd want to, like, standardize amongst clients?

Bharath:But, outside that, yeah.

Parithosh Jayanthi:Yeah, portals.

Potuz:Yes, this was… this has been discussed extensively for over a year, and I think it's pretty clear that the Builder API

Potuz:will have to be implemented on CL clients. We already have some ideas of what has to be signed, to whom it has to be signed. This is most of the contacting builders to get a bid.

Potuz:And I think we were very clear from the start that CL clients themselves, vanilla CL clients themselves, should have this functionality to be able to contact a builder directly, which is one of the functionalities of MevBoost.

Potuz:Mapboost does other things, like, for example, exchanging a blinded payload, that was signed, and this will not be implemented by clients, at least this will not be implemented by PRISM.

Potuz:And I think this was also very clear from early on. So I don't… I mean, this thing of, like, contacting directly builders, is something that, yes, it's expected to be part of the builder API, and it should be specified.

Bharath:Just to clarify on one thing, when you mentioned that,

Bharath:MevBoost also does blind signing, yes, it does do blind signing today, but with EPBS, we really will not have blind signing, unless… if in some future we have an unstake builder API, but just to clarify, that's what you mean, right, when you talk about blind signing, because with EPBS, I don't see where we're gonna have blind sign.

Bharath:Yeah, okay, sounds cool.

Bharath:Oh.

Dustin:Protas, when you talk… oh, sorry, yeah?

Bharath:Alright, go ahead, Dustin, sorry.

Dustin:Oh, question for Podas. When you kept talking about builders, do you mean…

Dustin:PEPBS-type, quote-unquote, builders, or do you mean builders in a, flew when… before, Builder API context.

Potuz:The CL client cannot distinguish from them, right? So if you contact a URL, and that URL gives you a signed bid.

Potuz:from a builder, the CL doesn't really care. It trusts that.

Dustin:Yeah, sure.

Potuz:The endpoint returns a signed bid. As long as that interaction happens, that's fine. That endpoint could be a relay that grabs bids from other builders, and we don't care about that. So that part, of course, has to be implemented by CL clients, and we do have more or less a complete specification already set up.

Dustin:Right, but I guess… I'm mostly confused, and I'm confused in the sense of, there's… what this current proposal, I mean, without…

Dustin:getting too deep into the technical details, it's both lacking things that, if you really want to absorb all of what… especially talk about, like, what CommitBoost does, or, like, if you want to absorb all of that functionality, it's lacking a lot of, sort of, specification related to that. Whether that's a good idea is a different question. At the same time, like.

Dustin:the Builder API, to talking with MedBoost.

Dustin:uses the Builder API. MevBoost both speaks the Builder API to the relays, and also is spoken to by the Builder API by CLs. That exists today. That is a status quo, right now, for every CL. So when I… so every CL that supports MEV right now already supports the Builder API.

Dustin:And if you're saying there's… there's no difference between, well, you know, there's the builder… builders and relays, because they… you're… of course, they can't tell the difference. If… if you want… if, you know,

Dustin:So, but at that point, what is actually being proposed here? Is it being… is it a standard for how to specify the multiplexing? Because that is it. That is the one… I mean, EPBS adds the not,

Dustin:blinded part. But, okay. But in terms of structurally speaking, the one and only thing different

Dustin:here is… is specifying the multiplexing. And that's what… where my skepticism is… is of saying, well, look, that's, to me, just an implementation thing.

Dustin:and this was a saying critique made… I mean, doesn't mean we can't specify it at some level, but I mean, it's the same critique made by a couple of the EIPs this cycle,

Dustin:In… on the EL side as well.

Dustin:the max blobs, right? Has this very, a very, I mean, much simpler idea, a much simpler thing, but is it, like, that's not really spec, exactly. I mean, that's a separate argument, and this is not the time or place to get into it, but that's sort of this critique that was made of it, and that's the same critique I would make here, is that if you have the…

Dustin:Like, it's a per-client UX thing.

Dustin:Right? Yeah. And that's… I would… I would want to be a lot of clarity about what exactly is… is this proposal getting us? Yeah.

Parithosh Jayanthi:Yeah, Enrico, and I think we have to end after that.

Enrico Del Fante (tbenr):Yeah, just a quick comment. We tend…

Enrico Del Fante (tbenr):To try to have the complexity of clients lower, so if we have something like this kind of multiplexing complexity that could be off-client, and having some intermediate

Enrico Del Fante (tbenr):software that can… does that. We see the benefit of that, because we can, yeah, lower down all the complexity, but…

Enrico Del Fante (tbenr):I think, like, the point here was…

Enrico Del Fante (tbenr):To support only the in-protocol builder flow, or the…

Enrico Del Fante (tbenr):Kind of blind signing, flow that is kind of trying to do the off… completely off-protocol bidding.

Enrico Del Fante (tbenr):Going through, and…

Enrico Del Fante (tbenr):I don't know if Bart was… was referring to that or not, but I agree with Podos that the current

Enrico Del Fante (tbenr):Thing that clients needs to be implemented is essentially what we, what we have now.

Enrico Del Fante (tbenr):In terms of builder flow, removing completely the, the blinded thing that is just,

Enrico Del Fante (tbenr):Less complexity anyway, so…

Parithosh Jayanthi:Yeah, Bharat, would you be able to create maybe a thread on, consensus dev, and then you can continue the temp check there?

Bharath:Yeah, we have a thread in the… I raised it in Payload Builders, the channel. I can just, like…

Parithosh Jayanthi:buffet.

Bharath:I'll, yeah, I'll forward that, and, like, we can take the discussion there, but yeah, I have my thoughts. Like, we can talk.

Parithosh Jayanthi:Sounds good.

Parithosh Jayanthi:And, I don't think we're gonna be able to get to it, but flagging it for async discussion, there's a PR4817 that Portos and Justin wanted to discuss. We don't have time on the call, but maybe you guys can bring it up on the CL dev… consensus Dev chat as well.

Parithosh Jayanthi:Okay, then that's it for today. Thanks, everyone, for coming, and sorry for going over.

jochem-brouwer:Thanks, Haul. Bye-bye.

Stefan Starflinger:Thank you. Bye.

Ansgar Dietrichs:Bam.

Chat Logs

Stefan Starflinger:https://github.com/ethereum/pm/issues/1878

Parithosh Jayanthi:https://github.com/ethereum/pm/issues/1878#issuecomment-3759492134

spencer-tb:Lets keep it in then if CLs are happy!

Parithosh Jayanthi:https://github.com/ethereum/EIPs/pull/11094

Marius van der Wijden:iirc lightclient was against this PR?

Stefan Starflinger:CL changes required for EIP 7843 https://github.com/ChainSafe/lodestar/pull/8736

Parithosh Jayanthi:https://github.com/ethereum/execution-specs/pull/1401#issuecomment-3759373893

Toni Wahrstätter:Context regarding EIP-7778: https://discord.com/channels/595666850260713488/688075293562503241/1461678093289656524

Justin Traglia:Replying to "CL changes required ..." There’s a specs PR too: https://github.com/ethereum/consensus-specs/pull/4840

Marius van der Wijden:I would prefer to change the receipts to add a second field

Francesco:I think EIP-8037 will also necessitate some change there, since block level accounting diverges from tx level accounting. Would be good to double check that the chosen solution works for it too (e.g. adding a second field would)

Ben Adams:Replying to "I would prefer to ch..." replace logsBloom?

Ben Adams:Replying to "I would prefer to ch..." Since that's not a used field anyway

Francesco:Replying to "I think EIP-8037 wil..." (Most likely I think it’s the same exact problem and whichever solution should work for both EIPs, but should just double check)

Guru:Replying to "I would prefer to ch..." The way it is currently specd out, I think the proposal is to create a new field

Marius van der Wijden:Replying to "I would prefer to ..." I also prefer a second field

Marius van der Wijden:Replying to "I would prefer to ..." Over reusing an existing field

Parithosh Jayanthi:https://github.com/ethereum/EIPs/pull/9003

frangio:has EIP-8024 already been discussed?

Parithosh Jayanthi:Ah wait, sorry it has been

Guru:Replying to "has EIP-8024 already..." Yes

Toni Wahrstätter:Replying to "I would prefer to ch..." Great, that's how it's speced right now. Sounds like we're good to go ahead with this 👍🏼

Parithosh Jayanthi:https://github.com/ethereum/EIPs/pull/9003#discussion_r2696677181

frangio:Replying to "has EIP-8024 alrea..." does anyone mind summarizing? i joined late and want to make sure there's understanding that we wouldn't merge the currently open PR

frangio:Replying to "has EIP-8024 alrea..." that would be my preference anyway

Jonny Rhea:Replying to "has EIP-8024 already..." I believe it was decided to not go with the push postfix.

Parithosh Jayanthi:https://github.com/ethereum/pm/issues/1878#issuecomment-3759492134

Potuz:Re: ePBS, it looks like the spec is finally frozen in what spectest vectors are concerned at least. We are now actively merging on Prysm's develop branch. Terence has about 9 PRs open that are being reviewed and they should all be merged in the next 2/3 days. Not sure about dates for kurtosis runs yet.

Łukasz Rozmej:7708 now behaves same as in eth_simulate?

Barnabas:Replying to "Re: ePBS, it looks l..." sounds like kurtosis runs are also scheduled for wednesday then 😄

Marius van der Wijden:Replying to "Re: ePBS, it looks..." What are the final timings?

Potuz:Replying to "Re: ePBS, it looks l..." what part of "not sure..." wasn't clear :)

Justin Traglia:Replying to "Re: ePBS, it looks l..." Yup. We could include the following fix into the devnet-0 specs, but it shouldn’t be necessary since we’re not testing builders on devnet-0. Reserve space for one validator sweep withdrawal: https://github.com/ethereum/consensus-specs/pull/4832

Marius van der Wijden:Replying to "Re: ePBS, it looks..." I mean for the slot

Marius van der Wijden:Replying to "Re: ePBS, it looks..." attestation timeline, ptc deadline etc

Barnabas:Replying to "Re: ePBS, it looks l..." https://github.com/ethereum/consensus-specs/blob/master/configs/mainnet.yaml#L102-L110

Stefan Starflinger:EIP-8024 moved to devnet-3 EIP-7843 included in devnet-2 EIP-7778 included in devnet-2 EIP-7708 included in devnet-2

Barnabas:https://notes.ethereum.org/@ethpandaops/bal-devnet-2

Mario Vega:Replying to "EIP-8024 moved to de..." EIP-8024 was completely moved or only the PR? I understood that only the changes were pushed but not sure

Justin Traglia:Variable PTC deadline: https://github.com/ethereum/consensus-specs/pull/4843

Jonny Rhea:Replying to "EIP-8024 moved to de..." @Mario Vega that’s what I thought too

Barnabas:these are all 1-3 lines changes in the config.yaml right?

Ansgar Dietrichs:+1 to the idea of a variable PTC deadline

Dustin:Replying to "these are all 1-3 ..." not variable PTC

Ansgar Dietrichs:also +1 to Potuz’ comments on making these timings dependent on real world data

spencer-tb:Replying to "EIP-8024 moved to de..." I think the PR!

Stefan Starflinger:Replying to "EIP-8024 moved to de..." I understood that the whole EIP was moved to devnet-3

Parithosh Jayanthi:Replying to "EIP-8024 moved to de..." Just PR

Parithosh Jayanthi:Replying to "EIP-8024 moved to de..." EIP is included

Potuz:11 days? no way for Prysm

Jonny Rhea:Replying to "EIP-8024 moved to de..." Okay to clarify…we are not going with the push postfix on devnet2, but might be considered for devnet3? Cc @frangio

Enrico Del Fante (tbenr):I don’t think we can, too

Dustin:and if they're "farthest ahead"...

Barnabas:prysm should be the farthest ahead

Dustin:the whole thing is Prysm's creation

Potuz:I don't think so, I suspect Teku is way before

Dustin:does that introduce more complexity though?

Matthew Keil:Sadly I think It does

Barnabas:we could limit the scope for devnet 0

Dustin:the PTC deadline etc still creates more than 3 intervals

Parithosh Jayanthi:https://notes.ethereum.org/@ethpandaops/epbs-devnet-0

frangio:personally i feel relatively strongly against this PR now. i'm writing down my reasoning

Marius van der Wijden:8037 explainer: https://notes.ethereum.org/@MariusVanDerWijden/SJD3CGdSbx Clarification to the eip: https://github.com/ethereum/EIPs/pull/11107

Parithosh Jayanthi:Unmuted but we can’t hear you

felix (eest):maybe just VERY quiet

Marius van der Wijden:1 sec

Potuz:@Justin Traglia Where/when can we make a decision on 4826 and 4817? I'd like a version of both be merged as soon as possible. Same for 4843 although the mechanism should be changed IMO to be on the validator.md file instead of a helper building the attestation. I think we should decide on those three soon and this call will not work. Can we set either a sync time on Discord or just decide there?

Parithosh Jayanthi:micDAO

Barnabas:Replying to "micDAO" we should launch a fundraiser for Marius to get him a new laptop/mic.

Francesco:Replying to "@Justin Traglia Wher..." Fwiw I am happy to revert having the helper if that’s a biocker

Barnabas:Replying to "micDAO" we should launch a fundraiser to swap out Marius for a better/more technical Marius

Ansgar Dietrichs:just to clarify, I might have said “separate metering for contract deployments” - but I meant “separate metering for all state growth operations, specifically to keep contract deployments possible”

Potuz:Replying to "@Justin Traglia Wher..." I think it makes the DA bit a bit complicated, we can merge as-is, and then deal with the bit later, but I'm pretty sure that we will need to remove the helper when we do so

butta:Replying to "micDAO" nobody told me you are good with jokes, barnabas

Potuz:Replying to "@Justin Traglia Wher..." I would rather include these changes earlier than later so that we can have some form of testing of the logic early enough.

Łukasz Rozmej:One thing from me TARGET_STATE_GROWTH_PER_YEAR should be a BPO parameter, so we can easily adjust it.

Parithosh Jayanthi:Replying to "micDAO" Wasting his talents by having him lift things at panda HQ

Justin Traglia:Replying to "@Justin Traglia Wher..." Yeah this call doesn’t feel like the appropriate place to discuss these in detail. I would prefer to discuss (async) these in threads on discord, come to consensus there, and then make the final call here.

Anders Elowsson:Replying to "One thing from me T..." In this case we should remove the scaling with the gas limit

Anders Elowsson:Replying to "One thing from me T..." This would simplify a lot of things

Anders Elowsson:Replying to "One thing from me T..." SGPO

Ansgar Dietrichs:any single tx can never be heavier to execute than the 16M limit. so I don’t think this should be a regression

Potuz:Replying to "@Justin Traglia Wher..." That works for me, just that Julian's PR has been up for a while. He mentioned he will have some numbers to have a better behaved constant (between 0 and the current 18 days)

Toni Wahrstätter:As I understood it, it wouldn't worsen execution parallelization in the worst-case. Instead of 4 max-size txs writing new state, you could only have one in a block.

Ben Adams:Replying to "As I understood it, ..." wouldn't that worsen it? 😅

Francesco:As mentioned in discord, there is no way to “parallelize state growth”. We have the tx gas limit because we can parallelize compute etc… but we just can’t do that with “state creation"

Justin Traglia:Replying to "@Justin Traglia Wher..." I feel like 4817 (onboard builders at the fork) could be merged now. Could we make a decision on this here today?

Ansgar Dietrichs:Replying to "As I understood it, ..." worsen it in what way? the block costs as much as a full block otherwise, but is as fast to execute as a single 16M tx

Ansgar Dietrichs:Replying to "As I understood it, ..." that’s fine

Anders Elowsson:Replying to "As mentioned in disc..." ..and don’t need to?

Ben Adams:Replying to "As I understood it, ..." min tx count before is 3.75; after is 1

Ansgar Dietrichs:Replying to "As I understood it, ..." but what is that min tx count useful for?

Francesco:Replying to "As I understood it, ..." Min tx count is not a useful thing to care about in itself

Łukasz Rozmej:Replying to "One thing from me T..." hm… disagree

Ben Adams:Replying to "As I understood it, ..." means paralellization of 1 rather than 4

Francesco:Replying to "As I understood it, ..." What we care about is: if a block consumes n x 16.7M regular gas, it has to have at least n txs

Francesco:Replying to "As I understood it, ..." means paralellization of 1 rather than 4 It doesn’t matter, because in that case the tx is still only 16.7Mgas

Ameziane Hamlat:Transaction state creation limit should go in hand with gas limit 👌

Potuz:Replying to "@Justin Traglia Wher..." I'm happy to merge that, couldn't find a bug yet

Justin Traglia:Replying to "@Justin Traglia Wher..." Cool, please bring it up at the end of the call.

Justin Traglia:Replying to "@Justin Traglia Wher..." If there’s time.

Potuz:Replying to "@Justin Traglia Wher..." cc @Parithosh Jayanthi

CPerezz:But can a corner case that might not happen (and has no strong issues/concern) kill the entire EIP which is beneficial ?

Parithosh Jayanthi:Replying to "@Justin Traglia Wher..." Bharath has a topic, that’s the only other one left

Parithosh Jayanthi:Replying to "@Justin Traglia Wher..." So there might be time depending on how long he takes

CPerezz:Is there any real alternative besides just do nothing and hope for the best?

Marius van der Wijden:Feels like the changes to the other eips that we are still discussing are in similar size as what we expect here

Ben Adams:Just highlighting is weird ux :)

Bharath:Replying to "@Justin Traglia Wher..." It is on absorbing MEV-Boost into clients. I am happy to discuss that with folks async

Marius van der Wijden:E.g. the receipts changes and push changes

Potuz:Replying to "@Justin Traglia Wher..." it's fine to have that one here and the PR on Discord, doesn't look like there's gonna be time for either anyway :)

butta:thx markus!

Bharath:Replying to "@Justin Traglia Wher..." Potuz and Tersec have given feedback on my PR and I can discuss it async and we can don’t have to drag the call for this. We can pick it up in ACDC if required

Marius van der Wijden:Marcus is from ethOS

Ben Adams:Will need to change headers and receipts also for this EIP to surface the stategas use

Marius van der Wijden:Replying to "Will need to change ..." Receipts yes, header not really

Francesco:If a smart contract would break because of dynamic cost, it will break with repricings

Marius van der Wijden:This would mean we would need to hard fork a few times a year

Francesco:Replying to "Will need to change ..." What would you need to add to the header? Imo we should change gasUsed to be max(regularGas, stateGas) (what the EIP calls gasMetered)

Francesco:Replying to "Will need to change ..." I implemented the EIP in the execution-specs and didn’t really see a reason to change the header

Ansgar Dietrichs:one question then: if we go ahead with CFI today, would people prefer to iterate purely async, or would there be use in a breakout call on this?

Ben Adams:Replying to "Will need to change ..." information loss just storing max()

Marius van der Wijden:Replying to "one question then: i..." Breakout rooms continue until morale improves

Ben Adams:Replying to "one question then: i..." Ok to CFI

Ameziane Hamlat:Let’s CFI it and discuss it more later

Francesco:Breakout call seems useful, there’s some details to discuss (e.g. exact way to split up the prices, whether there should be a header change, receipts…)

Anders Elowsson:Let’s keep an open mind on SGPO hardforks also. It can be very useful

Francesco:final_final_v2_definitive

Dustin:the basic question I'd have is, is this really a "spec" thing?

Dustin:i.e. multiplexing setup

Barnabas:I basically want to yeet mev boost if we can

Dustin:and I'd wonder scope-wise, e.g. extend to https://www.commit-boost.org/ ?

Dustin:CL clients implement the builder API now

Dustin:mev-boost is a bulider-API proxy

Dustin:that exists today

Dustin:right now

Ameziane Hamlat:Replying to "As I understood it, ..." But it is taking the whole block, so no place to other transactions to be included in that block

Francesco:Replying to "As I understood it, ..." Even with the tx gas limit, I can simply buy out all gas in the block. Why does it matter if I do it with one tx or 4?

Luis Pinto | Besu:Replying to "As I understood it, ..." Transaction parallelisation

Francesco:Replying to "As I understood it, ..." Can you say exactly what your concern is with that? The block we’re talking about has a single tx but it consumes only 16.7Mgas, we don’t need to parallelize anything

Ben Adams:BALs can do the internal tx IO parallelised so isn't such a problem (for a validator) and the builder who builds the BAL chooses to put it in (so additional effort in building the BAL is on them)

Ameziane Hamlat:Replying to "As I understood it, ..." Even with the tx gas limit, I can simply buy out all gas in the block. Why does it matter if I do it with one tx or 4? Yes, but you cannot guarantee that you’re going to use the whole block gas limit because transactions can go in different blocks, where with one transaction, you’re sure to use the whole gas of 1 block

Francesco:Replying to "As I understood it, ..." It’s the same as a post-BAL block that only contains a single tx because the builder wants it so

Potuz:I completely agree, we just need to specify the builder API and the only change is that we now can connect to many endpoints instead of one and it should not be speced how to connect to many endpoints

Potuz:@Dustin a hard request from the community was to standardize client flags so that operators can set the same flags across different clients

Potuz:things like min-bid, etc

Potuz:those things should be standardized on the builder API

Ameziane Hamlat:Replying to "As I understood it, ..." That’s actually for me what shouldn’t happen, having 1 tx consuming the whole block.

Ben Adams:Replying to "As I understood it, ..." Also you can put a whole bunch of additional txs in that only update state; even if all the state growth gas has been used

Dustin:Replying to "those things shoul..." the current approach ties this in to the builder proxy? i.e. the config gets unified there

Francesco:Replying to "As I understood it, ..." That’s actually for me what shouldn’t happen, having 1 tx consuming the whole block. Why? It was like this until Fusaka, and it’s not why we introduced the tx gas limit. Plus, builders can always just buy out a whole block

Dustin:Replying to "those things shoul..." (whether that proxy is named mev-boost or commit boost)

Justin Traglia:Yeah we’ll talk on discord

Francesco:Replying to "As I understood it, ..." Anyway, do we agree that the concern isn’t about parallelization?

Bharath:Replying to "those things should ..." Agreed that builder muxing is mostly implementation details. We probably want to standardize params like min-bid, bid-boost flags etc. Most of the PR specifies params like min-bid, bid-boost, max-trusted-bid etc

Justin Traglia:Bye everyone!

Summary

15 highlights · 6 decisions · 7 action itemsExperimental

bal devnet updates

bal-devnet-1 stable; most clients syncing, benchmarking deferred to devnet-200:02:58
bal-devnet-2 targets Wednesday launch with finalized Amsterdam EIP scope00:21:13

glamsterdam eip scope

EIP-7843 (SLOTNUM opcode) kept in devnet-2; engine API changes00:04:05
EIP-8024 (push postfix) moved to devnet-300:05:58
EIP-7778 adds new receipt field for post-refund gas tracking00:07:53
EIP-7708 uses system address for ETH transfer logs; withdrawals separate00:14:49
EIP-8037 CFI'd; dynamic state growth pricing with separate metering00:37:01

state growth discussion

8037 allows single tx consuming full block via state growth00:37:16
Single max-state tx still limited to 16.7M compute gas00:41:13
Dynamic pricing linked to gas limit; concerns about smart contract assumptions00:48:14
Gathering app developer feedback on dynamic cost implications00:51:18

builder api integration

Discussing absorbing MEV-Boost functionality into CL clients for Amsterdam00:54:24
Builder API must be implemented in vanilla CL clients00:56:45
Blind signing won't exist with ePBS; only direct builder contact00:59:08
Standardizing client flags (min-bid, bid-boost) in builder specs01:02:06

Decisions

EIP-7843 included in bal-devnet-200:04:24
EIP-8024 push postfix change rejected for devnet-200:07:35
EIP-7778 includes new receipt field for post-refund gas00:11:50
EIP-7708 uses system address; iterates on exact implementation details00:17:49
ePBS devnet-0 excludes external builders and P2P bid broadcast00:29:01
EIP-8037 moved to CFI; async iteration on dynamic pricing concerns00:53:08

Action Items

Spec editors: Merge EIP PRs for 7843, 7778, 7708 promptly00:14:15
EL/CL teams: Provide devnet-2 ready images to Stefan by Wednesday00:20:55
Testing teams: Update ePBS specs page with devnet-0 scope caveats00:31:47
CL teams: Review ePBS PRs 4826, 4817, 4843 async on Discord00:39:46
Marius/EF: Schedule breakout call for EIP-8037 iteration00:50:59
Maria Silva: Gather app developer feedback on dynamic state costs00:51:18
Bharath/CL teams: Continue builder API discussion async on Discord01:03:03

Targets

Wednesday (January 22) - bal-devnet-2 launch with Amsterdam EIPs00:21:10