All Core Devs - Testing #67

Transcript

Pooja Ranjan: Mario, Akash is having some internet issues, so I'll be helping with streaming today. Just let me know whenever you are ready.

Mario Vega: Okay, thank you so much.

Hey everyone, we just give a couple more minutes, for more people to join, and we can get started.

I think we have enough people now. Can we get started?

Pooja Ranjan: We are life.

Mario Vega: Excellent, thank you so much. Welcome, everyone, to ACDT number 67. Today is January 26th of 2026. Yeah, let's get just started. I shared the agenda in the chat. For everyone to see. First of all, we can get started with the Glamsterdam, I think it's the most pressing topic at the moment. Yeah, and for… for the first subtopic is… it would be more than the two, updates. The first thing that I would like to share is that we shared a… reference spec test release last week, and I'll link it in the chat for everyone to see. It basically contains all of the EIPs. That, are supposed to be included in the 2 for local access list.

I don't think there's much to say to it, unless, other than people should start just trying to use it, test their clients' implementations, and please raise any issues that you find in the Eat R&D Discord, so we can take a look. Or if there are any, any concerns, or any other thing, please just, just raise it so we can, we can, try to fix it. Alright, next to that, I think… Let me see… Stefan, are you, Nicole? I think you shared a very nicely comprehensive update in the… in the… in the issue, would you like to, get started on the… on this update?

Stefan Starflinger: Yeah, sure. So, just in general, I asked Tony if we could maybe push, the discussions on BAL open PRs, and I just listed the open PRs that we still have. And then, as a second point, I kind of went over to see how far clients currently are, and I created a nice table. The main blocker is the, slot num, EIP, so right now, most clients, don't make it through the Gloas fork, because they don't have the, engine methods. So it would be great if clients could merge those, or maybe give an update on that as well in a bit. And then, also, another point is that it would be great to have the flags to enable and disable the block-level access list optimizations.

That would really, unblock some of the repricing, efforts. Then I would ask for a quick update on the, kind of testing side, how the block-level access is incorporated in the tests to debug that. I think it would be nice for everyone to kind of get an update there. And that we should, go, like. try and get, BAL DevNet 2 running on Wednesday. So yeah, first of all, I would hand over to Tony, maybe to talk over, if you're here on the call, go over the individual open PRs.

Toni Wahrstätter: Yeah, let me quickly, pull it up, because I don't have it open right now. If I remember correctly, then for BAL DevNet 2, we wanted to have the JSON RPC methods implemented into clients, just to allow us, to easier debug stuff. Then there was an engine API method. I think we got to consensus in the PR there. basically why we are having those engine API methods. I think we wanted to discuss that on… in more depth on the… on Wednesday's block of Access List Breakout Call, so I won't go very deep into that one. but, yeah. Other than that, there's not really… Much more. Maybe, if Felipe is on the call, he might… might have something to add there.

With regards to the testing.

Felipe Selmo: Yeah, for… for now, we, The block level access list, used to be on the blocked object for blockchain. Trusts… And since we removed them from the block body, they actually, in the… 3.0.1 release weren't in the test vectors anymore. But that block body in tests, also includes an RLP field, So it's not really representative of a full block body, it just has block information in it. What we did in the last release is we just put the block-level access list back in these block objects in the blockchain test, so they are there in this 4.0.0 release. Just as they were in the previous file releases.

Mario Vega: Thank you. So just one comment regarding these open PRs, either Tony or Felipe or Stefan, is any of those… Blocking for .NET2?

Stefan Starflinger: Not any of these, necessarily, but it generally would be good to get them merged. So I thought maybe we could speed it up, because it seems like or maybe not all of them, but some of them shouldn't need too much discussion. For example, the one on the… execution APIs, adding slot number to fork choice update, I think that one would be great to merge, because that's really a blocker, for getting past the Gloas fork for this EIP.

Mario Vega: which number.

Toni Wahrstätter: Yeah, maybe…

Stefan Starflinger: I will share in the chat.

Toni Wahrstätter: And just to add to that. So, there are basically the three open PRs we're talking about. The first one is about adding the engine API method, so this is not necessarily needed, but depends on which CL client we're using, because, I think Lodestar, which we have been using so far, is not blinding the block level access lists, as they are not blinding the transactions, for example, which other clients do. So, this is not important in this case, if we keep using Lodestar. And the other one is more like an update to the EIP, so if my client is on the call, maybe, you could have approved that. This was basically, regarding your comment on the Discord channel, and the last one is the JSON RPC method, so also not really blocking, but nice to have.

Mario Vega: Alright, thank you. I think we can move on to the… second, part of your comment, Stefan, Basically, this is… this is stable… Let me… let me just share again the… the common link for everyone to be on the same page. This is the comment that we're referring to. The second bullet point in that comment contains a table. It's, basically the status of all the clients. Yeah, I just wanted to go client by client to see how they are in the implementation phase of this. I'll just start with Geth, because I think they're the further along in implementation, to see if they have any comments about either the EIPs or the implementation itself. Is anyone from Geth here who wants to comment on this?

For block-level access list, DevNet 2. Status?

Marius van der Wijden: I might be the only one from, from Geth here. As far as I know, so we have definitely implemented the… We have implemented the three, EIPs on top. like SlotNum, and BAL DevNet 2 should also work now. Like, the BAL part of BAL DevNet 2 should also work now. So, yeah, we are doing a lot of internal refactors to get some of the stuff merged into master, so that is where some of our time is spent, but, yeah, as far as I know, we should be okay for a definite.

Mario Vega: Okay, thank you. Thank you. Alright, moving on, Bessu, I see that you have local access 7708. Any comments on the… Status, anything that you want to share? I'm a project.

Daniel Lehrner: I… I… I… I can do that. So we have… Merged 7708, 7778, the gas refunds… And we have merged AT24 swap and Doop, and SlotNum is in review. And… oh yeah, for the e-logs, we have merged a version that The previous one that only had the transfer, that did not have a special topic for Smith District. self-destruct. We have also a PR in review that is adding that. So, all the… all the EIPs are either merged or in review.

Mario Vega: Excellent, thank you. Anyone from Reth? That's available.

Jen: Yeah, we have everything in progress, no blockers. I'm just taking a bit more time to review all PRs, and should be in by end of day. Unless there's some spec changes, and we might need to allocate more time.

Mario Vega: Thank you. Excellent. Anyone from Nethermind?

Łukasz Rozmej: So, We have, I think, everything implemented. There will be, probably last few slight changes to slot number. We are currently integrating it to one branch. It's not master, but it's a DevNet2 branch. And after DevNet2 will be stabilized, we'll probably integrate everything to master at that point, so that's our plan. Not sure about gas refunds, because there was some additional discussion around it, and Ben was… implementing that PR, and he's traveling now, so, not here. Anything else, Mark, you want to add?

Marc Harvey-Hill: No, nothing else, really. I think, yeah, we should have all of the, new IP… new EIPs merged soon.

Mario Vega: Yeah, and on 7778, I think we have a comment. I'll get to that in a bit. Let me just try to finish with the rest of the clients. But yeah, there's definitely some open questions and comments. Alright. From Erigon, do we have any… anyone here that can share some updates?

Andrew Ashikhmin: Yeah, so, with the bells, themselves, we are still finishing, some bits and pieces, Yeah, mostly, mostly done, and we should be ready this week, hopefully. With, 7708, It's, it's in review. With, 7778 gas refunds, Yeah, we'll probably have a discussion shortly afterwards, but, sorry, like, I, I… It was me who… I actually wanted to make some changes, but… Then I realized that it's very difficult to change receipts in Erigon. So, we can implement 7778 without receipt, like, changing the receipt.

With adding only an ephemeral field to the receipt, but it will be very difficult for us to implement it with a… Persistent field. 7843… we haven't started implementing it yet. I mean, it's probably an easy One, but it's not done yet. And, we have merged 80-24. So, when you say Wednesday, do you mean Wednesday this week, or Wednesday next week? Because I think we'll be ready by Wednesday next week, but not by Wednesday this week.

Stefan Starflinger: Preferably this week, but I can always, yeah, I mean, it would have been good to be done earlier, like Barnabas said, but generally, when… I think at least 3 clients already. And I hear out that we should have 3 clients ready by Wednesday to launch it, but we can always add clients as they get ready. Just to get it started.

Andrew Ashikhmin: Okay.

Mario Vega: Also, we can provide help with the consumption of the tests, so we have engine engine API tests in the release, which includes CellDump, so if you guys need help to run this, please reach out, to Felipe or myself, and we can help you out. Alright, thanks, thanks, Andrew. Anyone from Nimbus, just to finalize the status on the clients?

Dustin Brody: Yeah, yeah, moment. So, yeah, we are… this is in progress. We don't have them yet. I think… I think… This week would be… Hmm… ambitious? For us, but… Yeah. Oh, yeah, in progress.

Mario Vega: Alright, perfect. Thank you. Yeah, please keep us updated on the IT R&D. If you have something ready, please reach out to Stefan so he can help you out, to, just, point you out in the right direction. Alright, I think the main discussion point for a specific EIP seems to be 7778. Should we just proceed with that? Tony, I think you have the… you raised the discussion point on the agenda. Do you have more context on what you want to discuss regarding.

Toni Wahrstätter: EF.

Mario Vega: 7778.

Toni Wahrstätter: Yeah, so, right now, what we got in the specs is using the, gas used after the refund. Sorry, before the refund in accumulative gas used in the receipts, and we changed that recently. So this means, with EIP7778, there won't be any receipt changes needed. And clients can just continue dealing with the receipts as they are, for example, in EVGETransaction receipts. And I think Guru has already a PR open for this one, because I think we already merged, the other change, and now we need a new PR, Correct me if I'm wrong, Guru, if you're on the call. But I think we can just proceed with merging this. And… Yeah, the question is more like, how much time will clients need to implement that now?

How far are clients with 7778, and… If this doesn't, like, delay definite 2, because clients are busy with slot num anyway, then I would just say we implement that small change and get it into DevNet 2.

Mario Vega: Stefan, what's your preference? I think, from the testing side, we would have to make the change to spec, and just refill the tests, if I'm not mistaken. Maybe subtle changes in the tests. One or two PRs.

Guruprasad Kamath: Actually, yeah, on the specs and testing side, we have a draft PR up already, which makes all of these changes, so as soon as we make a decision. We should be good to merge that.

Stefan Starflinger: I don't have a strong preference.

Toni Wahrstätter: Yeah, maybe just to add to that, so this was basically the consensus after some discussion in this call. So, I think at this point, all clients agreed that this is the way how we should proceed. So, from that perspective, it's very clear. It's just a matter of, do we want to put it into DevNet2? Or… definite free. But this is like, okay, then we would change the receipt now, and change it back in definite free. So, this change is actually, quite a simplification, I would say.

Mario Vega: Yes, Andrew?

Andrew Ashikhmin: Well, so, for us, yeah, I just… Initially, I thought it would be easy for us to change the receipt format, but then I realized that it would be very difficult. So… For us, it's… there is a strong preference for Erigon to implement the version that doesn't require A change to the receipts. Otherwise… We won't be able to… it will take us probably a few weeks… well, at least maybe a couple of weeks to implement. the change, to the receipt format. So I strongly prefer To do the version that doesn't require the receipt form a change now.

Mario Vega: Daniel?

Daniel Lehrner: Yeah, so from Basel's side, we, as I mentioned before, we have merged 7778 as is with the modified, received. So we will need to revert this back… I cannot 100% guarantee that we could do this until Wednesday. So, I mean, how far doesn't need to specify today? We can make it, but if we change this now, it might take us, I don't know, one or two days to make the actual change back with the testing, I think. So there might be a slight… there might be a slight delay for us if we go with the adoption.

Mario Vega: Okay, thank you. There's a nice comment from Dragon in the chat, which is, what is better for the protocol? please think about that, I'll get back to that. Jen, do you have any comments?

Jen: Yeah, actually just wanted to plus one on what Dragon said, and from the rev side, we do have, right now, implemented according to the specs, so we'll also need to make changes. But yeah, I would like to discuss, first highlight why we are making this change, and what it means to the protocol, aside from how complex it is.

Mario Vega: Do you have any comments on what would be better for… In general. someone who's more familiar with this PR, this EIP, sorry, in particular, who wants to chime in?

Toni Wahrstätter: Yeah, so I think it's more an implementation detail, what we're discussing. It's like… I, I, I cannot, I cannot really answer how… Like, invasive it is to change the receipt. The clients I've talked to have been saying that it's not, like. A crazy thing to do, but of course, not doing it is… Like, easier to implement. So, if you look into the specs, as Guru has specced that now, it's a very simple change. And what it gives us, eventually, is just not allowing any transaction to Eventually caused more work than it. Pays for. Or eventually having blocks containing more work Then the block gas limit actually enforces. So this is the underlying rationale behind the EUP itself.

Mario Vega: Thank you. Yes, Maurice?

Marius van der Wijden: Yeah, so as I… as I understand this, there are two kind of Ways of thinking about, this field. Either if we don't change anything, then something for the users might change. So, either we change something for the nodes, in that we would need to store a secondary field that we will not Be able to, so, we will not be able to just load this data from somewhere, and then recompute it. In order to recompute this data, we would need to execute the execute the block, so the only way of kind of getting to this data is to also store it, which would mean we would need to store much… much more in the database, or, like, one field per receipt more in the database, per transaction more in the database, which is okay.

Because other fields from the receipts we can just load from the block. And they don't really cost us anything, storage-wise. And yeah, on the other hand, it is… it might be a usability issue for users, but overall. I think everyone wants this EIP, it's just…

Toni Wahrstätter: Yeah, maybe just to add, because this was, this was a great, description. And just to add, because Dragon has also, had a comment in the chat. So, there are two things we want. We need the gas used in a block, right? We need to enforce the block gas limit, and for this, under parallel execution. We need a way to know, was the block gas limit obeyed, even though transactions execute on different cores, on different threads. So this was also part of the discussion, why… That's why we need to always know, like, how much did the transaction account against the block gas limit. Versus how much did their user actually pay? So this has been part of a discussion, and…

There are two ways to deal with it, and both are fine with block access lists, and one is without a new receipt field. And the other, includes a new receipt field. And right now, I think there's, broad consensus that we eventually want to do it without a new receipt field, so… It's more like, do we want to delay definite tool launch until next week, which would mean we can implement this change. Or do we want to launch it? With the old version. Booked. This week.

Stefan Starflinger: So you're, like, 80-90% sure that this is the right way to go, to summarize. With this change.

Toni Wahrstätter: Yeah, it feels like it's less invasive, you know, because everything… around receipts will stay the same, because nothing changes from how clients use receipts today. The only thing that will change, and will become a little bit more complex, is enforcing the block gas limit when transactions are executed on different threads. Because you can't just take the receipt values and go through the gas limits and check if they could, at this point in time, still fit into the block. But, yeah, there are other ways how clients can deal with this, and this was also discussed. So, it seems like… We don't need many changes to make it work.

Stefan Starflinger: Okay, I generally tend… if we can get it in this week, this change, it doesn't have to be Wednesday, but if we can make it this week, then I'm for it, but I wouldn't want to wait until next week.

Toni Wahrstätter: Yeah, I'm also fine with delaying it. We can also delay it for definite free. It's a small change, and… Shouldn't block… shouldn't be a blocker.

Mario Vega: Andrew? Yes.

Andrew Ashikhmin: Well, if in DevNet 2 we go with the version that requires a receipt change, then probably in Erigon we'll have to skip DevNet 2, because, as I mentioned, for us, it's very difficult to change the receipt format. And there is no point in doing that work if it will be scrapped anyway.

Mario Vega: Okay, since I think it would be very valuable to have all clients on DevNet2, otherwise we will lose, information. I think delaying for a week seems to be, like, an okay solution. Is anyone opposed to this change? From the rest of the clients, it seems like an easy change for everyone else. Alright, if not, I think, what we need to do… Sorry, we're talking about 77… 7778, Lukash. We're deciding whether we are gonna change the receipt format or not, and just wanted input from the rest of the clients to see if we make another release of the tests in this, in the following days, for us to delay the net to… for next week. So we can get this change in, which would make it much easier for everyone to implement the EIP.

Łukasz Rozmej: So, for us, probably doesn't matter much. We can… Adjust.

Mario Vega: just to raise Dragon's command, we could do without the field in DevNet 2. Do you mean the change or not the change?

Dragan Rakita: I'm not sure what's specified currently in the IP. Either way, both things are very, like, nuisances, the main thing is AAP is good, it needs to be included. If we go with the field or without the field, those are details. I guess let's do what's easier. If it is easier to remove that field from the receipt, let's go with that. But I'm fine with that.

Mario Vega: Alright, and Marius asks, Tony if you can make the write-up in the discourse to make sure that everyone's aligned with the same thing. Alright. Alright, cool. So, yeah, let's move ahead, with the PBS for the sake of time. Is anyone here that has more context on EPVS status? Otherwise, we can go to the clients directly to see how is the progress with them implementing EPVS.

Justin Traglia: Let's start with the clients.

Mario Vega: Alright. Okay, let me just go, one by one. Anyone from Lighthouse?

Eitan Seri-Levi: Yeah, Lighthouse-wise, we're working on some consensus changes right now, so, fork choice, payload processing. Epoch stuff, and so we're aiming to have… start interoping, like, in a Lighthouse-only Kurtosis network in the following weeks. But there's still a lot of work left to do. But yeah, that's our update.

Mario Vega: Alright, thank you. Anyone from Teku who wants to share something regarding EBS?

Stefan Bratanov: Yeah, so not much update from TechCore compared to last time, the ACDC call last week. But we're having a couple more people working on it, so hopefully… We have some interop, block interrupt. Only Deco in the… Next couple of weeks, hopefully.

Mario Vega: Alright, thank you. Anyone from Prism who wants to share an update?

James He: I don't see Terrence or POTAs, but, we're making good progress on all the spec functions, and then we've just started on… some of the Beacon APIs, and I'll leave it up to Nico to kick us off on the issue, but, there is an area that, we should align on, for beacon API, statefulness.

Mario Vega: Yeah, but definitely, I'll get to that point, yeah, after client updates. Thank you. Anyone from Rimbus who can share an update?

Dustin Brody: Sure, so, I would say steady progress, so we've been kind of merging into… we learned, from Fusaka, where we've been merging into, And to trunk, I mean, in a… controlled way, but still a continuous way. So we have… The… envelope processing is kind of… and also, we have the… we already had a bunch of handling for, like, obviously the Gloss data columns, but now we're getting, I don't know, all this, like, a flavor here, I'm not a huge amount of detail, but, integrating that into the block production specifically, like, to… not just handling incoming, but creating our own. And broadcasting them, so those are the current open PRs, and… Fork choice is still, out there, though, and that's,

Yeah, I think the thing I want to point out about fork choice, actually, because this is a potentially a bigger… bigger issue than just EPBS, and a bigger risk factor in terms of deploying this, is we're going to end up having a choice, and it's why I think it's worth spending a little more time on in AC, you know, at least articulating its existence. there's a change in how ProposerBoost works, Alpha 1 did this, and there was some suggestions elsewhere, and fine. But the thing is, it is backwards and compatible. like… At least testing-wise, it is. And Nimbus hasn't done this, and a number of other clients haven't implemented the backwards part, backwards, you know, the previous, forks either. Now, what we're going to end up with is a choice of, do we do this all at once in… for…

For, you know, all of the forks? Or do we kind of, kind of… isolate this for GOAS, when we do this, for example, and… and they have their trade-offs. Anyway, so, for choice, that's, that's still out there, yeah. Anyway, so that's, that's where we are.

Mario Vega: Thank you. Just to finalize the client side, we can get back to fork choice, questions, and also the Bitcoin API afterwards. Lodstar, anyone from Loadstar with updates?

NC: Yeah, so last week we have implemented the Folk Choice. Except for the proposal boost part. And it's actively under review and testing. And, we also implemented the builder entity. So we are now passing the operation spec test of the alpha.1. spec tests? And we are now moving on to, block importing, and also exploring the state cache. Architecture.

Mario Vega: Alright, thank you. Can we just, go ahead with the Bitcoin API discussion, Nico, if you want to take it from there?

Nico Flaig: Yeah, sure. So, I left the summary of the proposed, or the options that we have here. So, currently, how the spec is done is that we have a two-step process for block production, which nicely maps on the internal beacon node state, because it's similar to how the P2P works, which has the beacon block separate to the execution payload. But I noticed the problem with that is, for local block production, that it's stateful, meaning, the beacon node that produces the beacon block is the one that also has the payload. And that one needs to be used to produce the execution payload envelope as well. So… and the issue with that is if you have a multi-node setup, and

stuff like Vouch or Vero that always requests from all beacon nodes. This kind of reduces the reliability of the block production. So that's… this is basically the option 1 I listed here, which is the current spec. We have two alternatives, I see. The second one is, to keep this two-step process. that you have to call two APIs, but, still call two APIs. But the execution payload request would return all block contents, which also includes the blobs, which is what we currently have. This would allow still to publish to all beacon nodes, so that property would still be there. But you still have the problem that only the beacon node that produced the initial beacon block is able to do that.

to, return the response for the payload. And then, option 3, that would keep it more like the status quo, where we call a single API, and then the… for the local block, we would return, as currently the beacon block, the execution payload, and blobs as well. That way, the validator client can then sign everything and publish it through all the existing or connected beaker nodes. So this is basically closest to what we have. Some issues there, or there are problems that were raised previously that blobs. The higher the blob count goes, the more data we have to pass around. I guess especially if you run Vouch or Vero, you want them on different servers, so latency is definitely something we should consider here.

But I think, yeah, this keeps it… closest to the status quo. It's not as nice from a spec perspective, but, so from the initial feedback, it seems like, most people are in favor of going with option 3. But yeah, definitely something to get more feedback on.

Mario Vega: Any comments from clients? Any preference, basically?

James He: Well, for definite zero, we're… we're just going with whatever is… We're going with the two-step process, right?

Barnabas Busa: Yeah, let's not change the scope of .NET 0. Let's, aim for all these changes for .NET1.

Nico Flaig: So, I guess it depends what's easiest for clients, so one thing with the two-step process is also that the beaconode that produces the block needs to cache the payload and the blobs, so I'm not sure that's currently implemented. Or at least, for example, I think, Dustin, you mentioned this might not be desired for you, so… I would say clients can just go with whatever is easiest for DevNet Zero.

James He: Yeah, we didn't implement the caching yet.

Enrico Del Fante: Do we really need to have this standardization for… Don't have zero anyway, so it's kind of just for client interrupts. We want to speed up everything, it's just… Let clients do. The quickest things, and then… I'll iron out the standardization later.

Nico Flaig: So I personally don't think we need to standardize this now, or for Definite Zero at least, but I think it would still be good if we can move ahead with the PR. to get this back up to the… or to get the PR merged soon, because it's pretty large, and there are other changes as well. But yeah, it's not that urgent, I would say.

Mario Vega: Nico, just one closing comment. So, what do you need from clients? Is it just reviews, or do you need anything else to move this PR forward?

Nico Flaig: Yeah, so just the general reviews on the PR, and then just feedback on what options clients would prefer. I think if there are not no good arguments for option 1, like how it's currently spec'd, then we should probably go with option 3 to keep the status quo.

Mario Vega: Okay, great. Excellent. So please, clients, if you can chime in into this PR, perhaps not the most pressing issue, but it would be helpful. please do so. I think the link is on the agenda. I'll also share it here again. For everyone to see. Great. Any other comments on this? I wanted to go back to Dustin's comments on fork choice. Do you want to expand on that? Do you feel like we should, Get something decided on this call, or is it something that, Yeah, in general.

Dustin Brody: Sure, well, so I see, NC also, commented on this, and, and basically there was a discussion there. To summarize the Discord discussion briefly, it's that, it looks like they are the different fork choice variations, let's say, can, can coexist. So that, So I guess I'm not sure… it… The only thing that would end up having to be, I think, sort of, and this call, relevant, decided is, is it, like. It seems like people are pretty confident that this is, in fact, a… Not a breaking change in the way that they say the withdrawals were, that would have been a breaking change, as it had turned out. That were withdrawn from the pre-Gloas setup. But this is, the tweaks to ProposerBoost and being on the canonical chain and all that, and that's… it's fine if clients do either, and if it's fine if clients do either, then I don't think it's that important to decide now.

What, like, in terms of interoperability.

Mario Vega: Distant Rico?

Enrico Del Fante: Yeah, if I remember correctly, this is… this was just a change that was… that's just… I decided to go backward into Phase 0. Just because it's covering… an edge case… So, it was… Fine to get this… to put this change to phase 0. And… I feel like maintaining two different versions just because of that tiny change is, Yeah, complication that we should not… do, if this is the question from Dustin. And, so if there's anything that needs to be updated on the test, or a line that goes back to phase zero, I would just make this thing test-related and not production code related to maintain two different behaviors, and it's actually a bug fix, as far as I understood, so…

I would like to have that. From Phase 0 and just update tests. And have one worship.

Dustin Brody: Okay. I mean, I mean, Steve, I guess, Steve, the question I wrote, though, which is. that I'm broadly, I'm not… as long as… Pushing back the… so backporting the changes is safe to the existing production, sort of forks, which are, obviously, for the EF ones, they're… they're foolu at this point, Fusaka, and then Electra or Pektra for… Gnosis is still on that, so…

Enrico Del Fante: cry.

Dustin Brody: As long… as long as it's safe. We… I don't… I don't care at all about Pre-Pectra. I…

Enrico Del Fante: So, the actual question is, is this edge case being exploited on mainnet since the beginning of the Beacon chain? And I would say. No, but I live…

Dustin Brody: But can it be? Right, but now that is very public, the question is, if… once clients diverge in their implementations, is this a wedge that an attacker can use? And is it actually… and crucially, is it worse to have that wedge than it is to have a suboptimal proposal boost implementation? Like, I haven't seen a real analysis of this. Just, like, whatever, just do it, go ahead. Yellow. And that's not sufficient.

Mario Vega: Alright, I wanted to, see if… Justin, could you… could you chime in on this? Do you see this as a problem, or, should… also, we should, timebox this discussion, just for the sake of, continuing on to other topics? Yeah.

Justin Traglia: I don't have much to say, really. I mean, I wish Francesca were here to chime in. We can chat about this more on Discord, I think, but I don't believe there are issues. Like, I don't think there could be, like, a… I don't think that… A divergence in implementations of, this. will cause issues. Yeah.

Mario Vega: Alright. Anyway, if you want to bring, this topic into the 8th R&D Discord, Dustin, just… Just for clarification, yes, please do so, so we can continue async. Is that… is that okay? Alright.

Dustin Brody: Yep. Yeah, yeah, yeah.

Mario Vega: Alright, thanks. Let's move on. Anything else related to EPVS that we should discuss in this call? Or anyone wants to bring up?

Justin Traglia: I can very quickly mention that we are working on, specs for the next DevNet, so, Alpha 2 release. I have made an issue with, deadlines in this, so we plan on freezing the specs on February 6th, and making the release on February 13th. Just so there's time to iron out any issues. FYI. I shared a link in the chat. Yes, that's correct. And, there are just two open PRs at the moment. the, changes to the minimum builder withdrawal, delay, and, the variable PTC deadline PR. Bye, Francesca.

Mario Vega: Alright, thank you. Excellent. Yeah, I think the next topic is, gas benchmarking. Anything that we want to discuss in this call today, or any updates, anyone wants to bring up?

Kamil Chodoła: So, nothing in particular for now. I'm in discussion on the new version of Gas Benchmarks, which is done by EF DevOps team right now. In the meantime, we are working on repricings. We got some messages from Maria that data is right now better, and working in the meantime on stateful testing to push the data for stateful scenarios, to decide on the repricings for those uploads. And that would be basically it, so, for now. The data analysis is happening.

Mario Vega: Alright, thank you. Great. Anything else regarding gas prices or benchmarking?

Louis Tsai: and built-in site, I will try to create a benchmark release. that supports Osaka. that tries to run the benchmark under Osaka 4. this week.

Mario Vega: Excellent, thank you, Liz. Good. Okay, if nothing else, we can, go into the next… last two topics for this… for this call. The first one is regarding process. and specifically the CFI EIP to DevNet process, which is what we generally talk about during this call. I made a comment. on the… on the issue agenda, the last couple of days. And basically, I think… We should have, like, more defined, and clearer process for everyone to, when we want to move something from CFI into DevNet, because I think there's definitely some room for improvement regarding how this was handled. In this stepnet, and definitely we can improve. So what I shared here is basically just a suggestion that maybe we can follow. I think the main issue was the first point that we didn't do properly for this, DevNet, which is,

that every EIP that is gonna be proposed for inclusion in a DevNet, we should post it ahead of time in the ACDT agenda. for every client to, review, to chime in, to raise any objections, and suggest alternatives. After that, if there are no, no major issues or major, objections raised by the clients, that is then, brought up in the… during the call. for a second chance to… for objections, and if there is none, then just basically we start working on the EIPs that have been, just approved by everyone in the… in the DevNet. Nevertheless, if, after that point, we still discover that there are issues that only are surfaced when the implementation has started by the clients, or the implementation has started by the specs and tests, this… the EIP should be proposed for removal from the devnet and just defer to a future devnet at any point, if that's the case.

And the last bullet point is basically that this call should never be use to make decisions regarding CFI to CF… SFI, moving of the, of the status of an EIP, or CFI to DFI. They will not be discussed during this call. Basically, that is, still needs to be discussed within ACDE and ACDC. This is basically, a place for discussion just for anything that we want to add that has already been approved as CFI. in the ACD, E or ACDC, and we discuss it here, just to move into it, to start testing procedures. having said that, I just want to hear from people, basically if this sounds like a… like a good idea, any… any… any comments, or how this should be handled in the future, if there's any…

Issues with this process, Other than that, what is raising this comment? And one comment from Ansgar is definite inclusion decision, not basically an SFI decision? Yeah, Ansgar?

Ansgar Dietrichs: Yeah, and I mean, it was just a, just something that came to mind, because I feel like, to me, yeah, the inclusion of an EIP into a DevNet at least means that now, if we end up not actually SFI it, not having it be included in the fork in the end, then that was, of course, extra effort that might have been wasteful in retrospect. And so I feel like there's this very real tension. On the one hand, I think making all… debit decisions? only on ACDE or something, or ACDC, of course, that adds extra friction. So, in principle, I do like the idea of just continuing to do that on ACDT. But then, on the other hand, it feels like, kind of like, just saying, oh, but, like, we moved the SFI decision over. That, in a sense, on its own, also seems a bit artificial. So I don't know, I was just curious how you think about that tension between…

The definite decision and the status decision.

Mario Vega: Yeah, definitely, I wouldn't suggest that on ACDT we decide on a big EIP to be included in a DevNet. That would be… erratic. For example, the ones in this, round. Basically because they are easy, quote-unquote, to implement. But yeah, that proved… that proved, as always, like, to be not the case, not the exact case for all the EIPs, so it's never gonna be, like, a silver bullet that we decide on the easiest, or, things to add to the devnet that are the easiest. Definitely, we shouldn't include an ACDT, something that is very big, like block-level access lists, or something of a bigger complexity, in my opinion. But yeah, I'm not sure. To be honest, I'm not sure if we should decide on ACDE, what to include on DevTent, or we should do it here.

Barnabas, do you have any opinion on this, or Stefan, do you have.

Barnabas Busa: Yeah, so basically, I think that, you know, CFI status is basically every EIP that we want to have implemented, whether it's going to be included in mainnet or not, is going to be up to ACD later on in ACDE or ACDC. But every single CFI EIP should be implemented by the client, and then… then we can evaluate if it's actually something that we want to SFI, and actually want to push out on mainnet. So, I think making the CFI to SFI decision is up to ACDE and ACDC, but whether or not to implement CFI EIP should really be up to ACDT, and just, Yeah, I think ordering it on which EIP should be implemented first can be… the decision can be made on this call.

Stefan Starflinger: I also generally agree with that, and I think, like, only because you have an implementation doesn't mean that it's going to go into the protocol. You should really have a working implementation before the spec is really finalized, and before we have a clear idea if it's something we want in the protocol. So, generally, I think that's a good suggestion, Mario.

Mario Vega: I also feel that we have… we gain a lot of information about EIPs once we start implementing, because before that, it's like. Best guess scenario, while… when we add things to the DevNet, we end up, like, really knowing the IP's problems, issues, and implementation details that turn out to be perhaps something much more, difficult to implement. I would like to ask client devs, how do you feel about this in general, or… And there's another comment from Ansgar. What's the general connection between implementation and DevNet? Are they usually implementations before DevNet inclusion? How easy it is to pull individual EIPs back out of a DevNet? This is just personal, it depends, right? Yeah, it depends.

Barnabas Busa: how big of an EIP are we talking about? If it's a, you know, one-line change, it's very easy to revert. If it's a very significant change, then yeah, the bigger, the harder it is.

Dustin Brody: It's not just sheer size, I would say we saw this in Pectra, for sure, that we had EIPs and, to some degree, Fusaka, not individually huge, but they were 3 or 4 or 4 of them, very, intertwined. They all change the same code, the same data structures, the same SSC objects. and… effectively, I mean, yeah, they were different EIPs, but they were one unit of change, practically speaking, in terms of implementing them, and it would be almost as much effort to remove one as to implement, at least from Nimbus, as to have implemented all of them together, almost. Yeah.

Mario Vega: Tony, I don't think there's a conclusion, Yeah, last… one last question from Ansgar. Would it be too botaractic to have an initial decision on a DevNet scope, but then, a week later, on the next ACDT, make a go-no-go decision? That way, clients would have a week to look at the selected EIPs and start implementation? So we could catch the EIPs that are more complex than expected.

Barnabas Busa: That's way too much overhead, in my opinion. Let's go.

Ansgar Dietrichs: Okay, yeah, sorry for all the questions. I was just, you know, kind of from the ACDE kind of side, just trying to understand things a bit better, but yeah, yeah, no, I mean, makes sense then. I was just curious.

Mario Vega: I think, yeah, definitely we should be more careful about, with GIPs, because even though they look like one-liners. That's not always the case. But I think this is… this process can definitely evolve. If we catch something, any IP, for example, that is suggested to go into a DevNet, and someone sees that this is not feasible. We'll make sure that we want to share on the agenda prior to the call, just for everyone to, like, raise the question, either during the call or before, even. for us to, like, try to minimize the burden. Also, this raises the question whether… when are more complex EIPs gonna make the cut? Which is, I think, that's something that we have to keep discussing.

We're out of time at the moment. But yeah, definitely, I don't think it's resolved. I don't think there's, like, a perfect process, anyway. So, we can bring up this topic again in next week's call, if necessary. There was one, just, just one more, open, comment by Pooja. I just want to very quickly give you the chance to share it, Pooja, if that's okay, before we close the call.

Pooja Ranjan: Yeah, thank you so much, Mario. I wanted to share a few things, a few PRs which are made for BPO-related stuff. Thank you, Mario, for sharing that. So, in the first PR, I have requested to suggest, open a folder for BPO in order to keep track of progress and everything that general community would want to see, and this folder is suggested on Ethereum slash PM GitHub repository. Apart from it, there are other two PRs in the EIPS repositories, and those are with respect to the Meta EP for BP01 and BPO2. In a way, BPO1 and BPO2 are also the network upgrade, the hard fork parameters only, but it reaches the stature of a hard fork, so I believe that there should be Meta E for these two BPOs as well, and we should make Meta E for upcoming BPOs upgrade.

I have added the link to these Meta Eats. kindly take a look, and yeah, just let us know your opinion. There were a couple of open questions that I wanted to share with this group here to decide and let us know. I would love to hear from the team, if there is any preference in representation of BPO when we are documenting it. There are 3 different styles. It could be BPO1, BPO Space 1, and BPO-1, whatever is preferred way. I have used BPO1 in the EIP, but if there is any other preference, please let us know. And I'm happy to update the proposal. And also, if we can get an estimate on how many BPU upgrades we are expecting a year, that would also be helpful in making a decision. I have tried to list most of the obvious question in the Fellowship of Ethereum Magician for people to refer to.

If there is any strong opposition for this EIP, please drop a comment and general support, as well as any suggestion to improve this proposal are already welcome. Thank you so much.

Marius van der Wijden: Bye, guys.

Pooja Ranjan: All right. Thank you, everyone. Bye-bye.

Andrew Ashikhmin: Thank you, bye-bye.

Justin Traglia: Alright, bro.

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