AllCoreDevs - Testing #067

|2026-01-26| Agenda: #1882| canonical JSON

Transcript

Mario Vega: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.

Mario Vega:For everyone to see.

Mario Vega:First of all, we can get started with the Glamsterdam, I think it's the most pressing topic at the moment.

Mario Vega:Yeah, and for…

Mario Vega: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…

Mario Vega: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.

Mario Vega:That, are supposed to be included in the 2 for local access list.

Mario Vega: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.

Mario Vega: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.

Mario Vega:Alright, next to that, I think… Let me see…

Mario Vega:Stefan, are you, Nicole? I think you shared a very nicely comprehensive update in the… in the…

Mario Vega: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.

Stefan Starflinger:And then, as a second point, I kind of went over to see how far clients currently are, and I created a nice

Stefan Starflinger: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.

Stefan Starflinger: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.

Stefan Starflinger:That would really, unblock some of the repricing, efforts.

Stefan Starflinger: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.

Stefan Starflinger:And that we should, go, like.

Stefan Starflinger: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.

Toni Wahrstätter:Then there was an engine API method. I think we got to consensus in the PR there.

Toni Wahrstätter: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.

Toni Wahrstätter:but, yeah.

Toni Wahrstätter:Other than that, there's not really… Much more.

Toni Wahrstätter:Maybe, if Felipe is on the call, he might… might have something to add there.

Toni Wahrstätter:With regards to the testing.

felipe:Yeah, for… for now, we,

felipe:The block level access list, used to be on the blocked object for blockchain.

felipe:Trusts… And since we removed them from the block body, they actually, in the…

felipe:3.0.1 release weren't in the test vectors anymore.

felipe:But that block body in tests, also includes an RLP field,

felipe:So it's not really representative of a full block body, it just has block information in it.

felipe: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.

felipe: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…

Mario Vega: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

Stefan Starflinger:or maybe not all of them, but some of them shouldn't need too much discussion. For example, the one on the…

Stefan Starflinger: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.

Toni Wahrstätter:So, there are basically the three open PRs we're talking about. The first one is about adding

Toni Wahrstätter: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

Toni Wahrstätter:the transactions, for example, which other clients do. So, this is not important in this case, if we keep using Lodestar.

Toni Wahrstätter: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.

Toni Wahrstätter: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.

Mario Vega:I think we can move on to the…

Mario Vega:second, part of your comment, Stefan,

Mario Vega:Basically, this is… this is stable…

Mario Vega:Let me… let me just share again the… the common link for everyone to be on the same page.

Mario Vega:This is the comment that we're referring to. The second bullet point in that comment contains a table.

Mario Vega:It's, basically the status of all the clients.

Mario Vega:Yeah, I just wanted to go client by client to see how they are in the implementation phase of this.

Mario Vega: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.

Mario Vega:Is anyone from Geth here who wants to comment on this?

Mario Vega:For block-level access list, DevNet 2.

Mario Vega:Status?

Marius van der Wijden:I might be the only one from, from Geth here.

Marius van der Wijden:As far as I know, so we have definitely implemented the…

Marius van der Wijden:We have implemented the three, EIPs on top.

Marius van der Wijden:like SlotNum, and BAL DevNet 2 should also work now. Like, the BAL part of BAL DevNet 2 should also work now.

Marius van der Wijden: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.

Mario Vega:Thank you. Alright, moving on, Bessu, I see that you have local access 7708.

Mario Vega:Any comments on the… Status, anything that you want to share?

Mario Vega:I'm a project.

Daniel Lehrner (Besu):I… I… I… I can do that. So we have…

Daniel Lehrner (Besu):Merged 7708, 7778, the gas refunds…

Daniel Lehrner (Besu):And we have merged AT24 swap and Doop, and SlotNum is in review.

Daniel Lehrner (Besu):And… oh yeah, for the e-logs, we have merged a version that

Daniel Lehrner (Besu):The previous one that only had the transfer, that did not have a special topic for Smith District.

Daniel Lehrner (Besu):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.

Mario Vega:Anyone from Reth?

Mario Vega: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.

Jen:Unless there's some spec changes, and we might need to allocate more time.

Mario Vega:Thank you.

Mario Vega:Excellent. Anyone from Nethermind?

Łukasz Rozmej:So,

Łukasz Rozmej: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.

Łukasz Rozmej: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…

Łukasz Rozmej:implementing that PR, and he's traveling now, so, not here.

Łukasz Rozmej:Anything else, Mark, you want to add?

Marc: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.

Mario Vega: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,

Andrew Ashikhmin:Yeah, mostly, mostly done, and we should be ready this week, hopefully.

Andrew Ashikhmin:With, 7708, It's, it's in review.

Andrew Ashikhmin:With, 77.78 gas refunds,

Andrew Ashikhmin:Yeah, we'll probably have a discussion shortly afterwards, but, sorry, like, I, I… It was me who…

Andrew Ashikhmin:I actually wanted to make some changes, but…

Andrew Ashikhmin:Then I realized that it's very difficult to change receipts in Erigon.

Andrew Ashikhmin:So, we can implement 7778 without receipt, like, changing the receipt.

Andrew Ashikhmin:With adding only an ephemeral field to the receipt, but it will be very difficult for us to implement it with a…

Andrew Ashikhmin:Persistent field.

Andrew Ashikhmin:7843… we haven't started implementing it yet. I mean, it's probably an easy

Andrew Ashikhmin:One, but it's not done yet.

Andrew Ashikhmin: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.

Stefan Starflinger: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.

Stefan Starflinger: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

Mario Vega: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.

Mario Vega:Alright, thanks, thanks, Andrew. Anyone from Nimbus, just to finalize the status on the clients?

Dustin:Yeah, yeah,

Dustin:moment. So, yeah, we are… this is in progress. We don't have them yet. I think… I think…

Dustin:This week would be… Hmm… ambitious?

Dustin:For us, but… Yeah.

Dustin:Oh, yeah, in progress.

Mario Vega:Alright, perfect. Thank you.

Mario Vega: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.

Mario Vega:Alright, I think the main discussion point for a specific EIP seems to be 7778. Should we just proceed with that?

Mario Vega: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.

Toni Wahrstätter: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.

Toni Wahrstätter:And clients can just continue dealing with the receipts as they are, for example, in EVGETransaction receipts.

Toni Wahrstätter:And I think Guru has already a PR open for this one, because I think we already merged,

Toni Wahrstätter:the other change, and now we need a new PR,

Toni Wahrstätter:Correct me if I'm wrong, Guru, if you're on the call.

Toni Wahrstätter:But I think we can just proceed with merging this.

Toni Wahrstätter:And… Yeah, the question is more like, how much time will clients need to implement that now?

Toni Wahrstätter:How far are clients with 7778, and…

Toni Wahrstätter: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.

Mario Vega:Maybe subtle changes in the tests.

Mario Vega:One or two PRs.

Guru: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.

Guru: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.

Toni Wahrstätter:So, from that perspective, it's very clear. It's just a matter of, do we want to put it into DevNet2?

Toni Wahrstätter:Or…

Toni Wahrstätter:definite free. But this is like, okay, then we would change the receipt now, and change it back in definite free.

Toni Wahrstätter:So, this change is actually, quite a simplification, I would say.

Mario Vega:Yes, Andrew?

Andrew Ashikhmin:Well, so, for us, yeah, I just…

Andrew Ashikhmin:Initially, I thought it would be easy for us to change the receipt format, but then I realized that it would be

Andrew Ashikhmin:very difficult. So…

Andrew Ashikhmin:For us, it's… there is a strong preference for Erigon to implement the version that doesn't require

Andrew Ashikhmin:A change to the receipts.

Andrew Ashikhmin:Otherwise…

Andrew Ashikhmin:We won't be able to… it will take us probably a few weeks… well, at least maybe a couple of weeks to implement.

Andrew Ashikhmin:the change, to the receipt format. So I strongly prefer

Andrew Ashikhmin:To do the version that doesn't require the receipt form a change now.

Mario Vega:Daniel?

Daniel Lehrner (Besu):Yeah, so from Basel's side, we, as I mentioned before, we have merged 7778 as is with the modified, received.

Daniel Lehrner (Besu):So we will need to revert this back…

Daniel Lehrner (Besu):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,

Daniel Lehrner (Besu):I don't know, one or two days to make the actual change back with the testing, I think.

Daniel Lehrner (Besu):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?

Mario Vega: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.

Jen: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.

Mario Vega: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…

Toni Wahrstätter:I, I, I cannot, I cannot really answer how…

Toni Wahrstätter:Like, invasive it is to change the receipt.

Toni Wahrstätter:The clients I've talked to have been saying that it's not, like.

Toni Wahrstätter:A crazy thing to do, but of course, not doing it is… Like, easier to implement.

Toni Wahrstätter:So, if you look into the specs, as Guru has specced that now, it's a very simple change.

Toni Wahrstätter:And what it gives us, eventually, is just not allowing any transaction to

Toni Wahrstätter:Eventually caused more work than it.

Toni Wahrstätter:Pays for.

Toni Wahrstätter:Or eventually having blocks containing more work

Toni Wahrstätter: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

Marius van der Wijden:Ways of thinking about, this field.

Marius van der Wijden:Either if we don't change anything, then something for the users might change.

Marius van der Wijden:So, either we change something for the nodes, in that we would need to store a secondary field that we will not

Marius van der Wijden:Be able to, so, we will not be able to just

Marius van der Wijden:load this data from somewhere, and then recompute it. In order to recompute this data, we would need to execute the

Marius van der Wijden: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…

Marius van der Wijden:much more in the database, or, like, one field per receipt more in the database, per transaction more in the database, which is okay.

Marius van der Wijden:Because other fields from the receipts we can just load from the block.

Marius van der Wijden:And they don't really cost us anything, storage-wise.

Marius van der Wijden:And yeah, on the other hand, it is… it might be a usability issue for users, but overall.

Marius van der Wijden: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.

Toni Wahrstätter:And just to add, because Dragon has also, had a comment in the chat.

Toni Wahrstätter: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.

Toni Wahrstätter:We need a way to know, was the block gas limit obeyed, even though transactions execute on different cores, on different threads.

Toni Wahrstätter:So this was also part of the discussion, why…

Toni Wahrstätter:That's why we need to always know, like, how much did the transaction account against the block gas limit.

Toni Wahrstätter:Versus how much did their user actually pay?

Toni Wahrstätter:So this has been part of a discussion, and…

Toni Wahrstätter:There are two ways to deal with it, and both are fine with block access lists, and one is without a new receipt field.

Toni Wahrstätter: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…

Toni Wahrstätter:It's more like, do we want to delay definite tool launch until next week, which would mean we can implement this change.

Toni Wahrstätter:Or do we want to launch it?

Toni Wahrstätter:With the old version.

Toni Wahrstätter:Booked. This week.

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

Stefan Starflinger:With this change.

Toni Wahrstätter:Yeah, it feels like it's less invasive, you know, because everything…

Toni Wahrstätter: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.

Toni Wahrstätter: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.

Toni Wahrstätter:But, yeah, there are other ways how clients can deal with this, and this was also discussed. So, it seems like…

Toni Wahrstätter: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…

Toni Wahrstätter: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.

Andrew Ashikhmin: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,

Mario Vega:information. I think delaying for a week seems to be, like, an okay solution. Is anyone opposed to this change?

Mario Vega:From the rest of the clients, it seems like an easy change for everyone else.

Mario Vega:Alright, if not, I think, what we need to do… Sorry, we're talking about 77… 7778, Lukash.

Mario Vega: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.

Mario Vega: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.

Łukasz Rozmej:We can… Adjust.

Mario Vega:just to raise Dragon's command, we could do without the field in DevNet 2.

Mario Vega: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,

Dragan Rakita: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.

Dragan Rakita:I guess let's do what's easier.

Dragan Rakita:If it is easier to remove that field from the receipt, let's go with that.

Dragan Rakita: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.

Mario Vega:Alright, cool.

Mario Vega:So, yeah, let's move ahead, with the PBS for the sake of time.

Mario Vega: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.

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

Eitan:Yeah, Lighthouse-wise, we're working on some consensus changes right now, so, fork choice, payload processing.

Eitan:Epoch stuff, and so we're aiming to have… start interoping, like, in a Lighthouse-only Kurtosis network in the following weeks.

Eitan: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.

Stefan Bratanov:But we're having a couple more people working on it, so hopefully…

Stefan Bratanov:We have some interop, block interrupt.

Stefan Bratanov: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…

James He:some of the Beacon APIs, and

James He:I'll leave it up to Nico to kick us off on the issue, but,

James He: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.

Mario Vega:Thank you. Anyone from Rimbus who can share an update?

Dustin: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,

Dustin:And to trunk, I mean, in a…

Dustin:controlled way, but still a continuous way. So we have… The…

Dustin:envelope processing is kind of… and also, we have the… we already had a bunch of handling for,

Dustin: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.

Dustin:And broadcasting them, so those are the current open PRs, and…

Dustin:Fork choice is still, out there, though, and that's,

Dustin: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

Dustin:articulating its existence.

Dustin: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.

Dustin:like… At least testing-wise, it is.

Dustin: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…

Dustin:For, you know, all of the forks? Or do we kind of, kind of…

Dustin:isolate this for GOAS, when we do this, for example, and… and they have their trade-offs.

Dustin: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.

NC:Except for the proposal boost part.

NC:And it's actively under review and testing.

NC:And, we also implemented the builder entity.

NC:So we are now passing the operation spec test of the alpha.1.

NC:spec tests?

NC:And we are now moving on to, block importing, and also exploring the state cache.

NC: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?

nflaig:Yeah, sure. So, I left the summary of the proposed, or the options that we have here.

nflaig: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.

nflaig: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.

nflaig: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

nflaig:stuff like Vouch or Vero that always requests from all beacon nodes. This kind of reduces the reliability of the block production.

nflaig:So that's… this is basically the option 1 I listed here, which is the current spec.

nflaig:We have two alternatives, I see.

nflaig:The second one is, to keep this two-step process.

nflaig: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.

nflaig:This would allow still to publish to all beacon nodes, so that property would still be there.

nflaig:But you still have the problem that only the beacon node that produced the initial beacon block is able to do that.

nflaig: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.

nflaig:That way, the validator client can then sign everything and publish it through all the existing or connected beaker nodes.

nflaig: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.

nflaig:I guess especially if you run Vouch or Vero, you want them on different servers, so latency is definitely something we should consider here.

nflaig:But I think, yeah, this keeps it…

nflaig: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.

nflaig:But yeah, definitely something to get more feedback on.

Mario Vega:Any comments from clients?

Mario Vega:Any preference, basically?

James He:Well, for definite zero, we're… we're just going with whatever is…

James He:We're going with the two-step process, right?

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

nflaig: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.

nflaig: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 (tbenr):Do we really need to have this standardization for…

Enrico Del Fante (tbenr):Don't have zero anyway, so it's kind of just for client interrupts.

Enrico Del Fante (tbenr):We want to speed up everything, it's just… Let clients do.

Enrico Del Fante (tbenr):The quickest things, and then… I'll iron out the standardization later.

nflaig: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.

nflaig: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.

nflaig: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?

nflaig:Yeah, so just the general reviews on the PR, and then just feedback on what options clients would prefer.

nflaig: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.

Mario Vega:please do so. I think the link is on the agenda. I'll also share it here again.

Mario Vega:For everyone to see.

Mario Vega: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,

Mario Vega:Get something decided on this call, or is it something that, Yeah, in general.

Dustin: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

Dustin:variations, let's say, can, can coexist. So that,

Dustin:So I guess I'm not sure… it…

Dustin:The only thing that would end up having to be, I think, sort of, and this call, relevant, decided is, is it, like.

Dustin:It seems like people are pretty confident that this is, in fact, a…

Dustin: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.

Dustin: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.

Dustin:What, like, in terms of interoperability.

Mario Vega:Distant Rico?

Enrico Del Fante (tbenr):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.

Enrico Del Fante (tbenr):Just because it's covering… an edge case… So, it was…

Enrico Del Fante (tbenr):Fine to get this… to put this change to phase 0.

Enrico Del Fante (tbenr):And… I feel like maintaining two different versions just because of that tiny change is,

Enrico Del Fante (tbenr):Yeah, complication that we should not…

Enrico Del Fante (tbenr):do, if this is the question from Dustin.

Enrico Del Fante (tbenr):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

Enrico Del Fante (tbenr):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…

Enrico Del Fante (tbenr):I would like to have that.

Enrico Del Fante (tbenr):From Phase 0 and just update tests.

Enrico Del Fante (tbenr):And have one worship.

Dustin:Okay. I mean, I mean, Steve, I guess, Steve, the question I wrote, though, which is.

Dustin:that I'm broadly, I'm not… as long as…

Dustin:Pushing back the… so backporting the changes is safe to the existing production,

Dustin:sort of forks, which are, obviously, for the EF ones, they're…

Dustin:they're foolu at this point,

Dustin:Fusaka, and then Electra or Pektra for… Gnosis is still on that, so…

Enrico Del Fante (tbenr):cry.

Dustin:As long… as long as it's safe.

Dustin:We… I don't… I don't care at all about Pre-Pectra. I…

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

Enrico Del Fante (tbenr):No, but I live…

Dustin: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?

Dustin:Like, I haven't seen a real analysis of this. Just, like, whatever, just do it, go ahead. Yellow.

Dustin: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?

Mario Vega: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

Justin Traglia:I don't believe there are issues. Like, I don't think there could be, like, a… I don't think that…

Justin Traglia:A divergence in implementations of, this.

Justin Traglia:will cause issues.

Justin Traglia:Yeah.

Mario Vega:Alright. Anyway, if you want to bring, this topic into the 8th R&D Discord, Dustin, just…

Mario Vega:Just for clarification, yes, please do so, so we can continue async.

Mario Vega:Is that… is that okay?

Mario Vega:Alright.

Dustin:Yep. Yeah, yeah, yeah.

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

Mario Vega:Or anyone wants to bring up?

Justin Traglia:I can very quickly mention that we are working on,

Justin Traglia:specs for the next DevNet, so,

Justin Traglia:Alpha 2 release. I have made an issue with,

Justin Traglia:deadlines in this, so we plan on freezing the specs on February 6th, and making the release on February 13th.

Justin Traglia:Just so there's time to iron out any issues.

Justin Traglia:FYI.

Justin Traglia:I shared a link in the chat.

Justin Traglia:Yes, that's correct. And, there are just two open PRs at the moment.

Justin Traglia:the, changes to the minimum builder withdrawal, delay, and, the variable PTC deadline PR.

Justin Traglia:Bye, Francesca.

Mario Vega:Alright, thank you.

Mario Vega: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.

Kamil Chodoła:In the meantime, we are working on repricings.

Kamil Chodoła: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.

Kamil Chodoła:And that would be basically it, so, for now.

Kamil Chodoła:The data analysis is happening.

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

Louis:and built-in site, I will try to create a benchmark release.

Louis:that supports Osaka.

Louis:that tries to run the benchmark under Osaka 4.

Louis:this week.

Mario Vega:Excellent, thank you, Liz.

Mario Vega:Good.

Mario Vega:Okay, if nothing else, we can, go into the next… last two topics for this… for this call. The first one is regarding process.

Mario Vega:and specifically the CFI EIP to DevNet process, which is what we generally talk about during this call. I made a comment.

Mario Vega:on the… on the issue agenda, the last couple of days. And basically, I think…

Mario Vega: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.

Mario Vega:In this stepnet, and definitely we can improve.

Mario Vega: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,

Mario Vega:that every EIP that is gonna be proposed for inclusion in a DevNet, we should post it ahead of time in the ACDT agenda.

Mario Vega:for every client to, review, to chime in, to raise any objections, and suggest alternatives.

Mario Vega: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.

Mario Vega: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.

Mario Vega:Nevertheless, if, after that point, we still discover that there are issues that only are surfaced when the

Mario Vega: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.

Mario Vega:And the last bullet point is basically that this call should never be

Mario Vega: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.

Mario Vega:in the ACD,

Mario Vega:E or ACDC, and we discuss it here, just to move into it, to start testing procedures.

Mario Vega: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…

Mario Vega:Issues with this process,

Mario Vega:Other than that, what is raising this comment?

Mario Vega: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,

Ansgar Dietrichs: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.

Ansgar Dietrichs:And so I feel like there's this very real tension. On the one hand, I think making all…

Ansgar Dietrichs:debit decisions?

Ansgar Dietrichs: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…

Ansgar Dietrichs: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…

Mario Vega:erratic. For example, the ones in this, round.

Mario Vega:Basically because they are easy, quote-unquote, to implement.

Mario Vega: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.

Mario Vega: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.

Mario Vega: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.

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

Barnabas: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.

Barnabas: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.

Barnabas:So,

Barnabas: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,

Barnabas: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

Stefan Starflinger: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.

Mario Vega:Best guess scenario, while…

Mario Vega: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.

Mario Vega:I would like to ask client devs, how do you feel about this in general, or…

Mario Vega: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?

Mario Vega:This is just personal, it depends, right? Yeah, it depends.

Barnabas: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: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.

Dustin:They all change the same code, the same data structures, the same SSC objects.

Dustin:and…

Dustin: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.

Dustin:Yeah.

Mario Vega:Tony, I don't think there's a conclusion,

Mario Vega: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?

Mario Vega:So we could catch the EIPs that are more complex than expected.

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

Barnabas: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.

Mario Vega: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

Mario Vega: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.

Mario Vega: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.

Mario Vega: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.

Mario Vega: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.

Pooja Ranjan: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.

Pooja Ranjan: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.

Pooja Ranjan: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.

Pooja Ranjan:I have added the link to these Meta Eats.

Pooja Ranjan: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

Pooja Ranjan: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.

Pooja Ranjan: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.

Pooja Ranjan: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.

Chat Logs

Mario Vega:Agenda: https://github.com/ethereum/pm/issues/1882

Mario Vega:https://github.com/ethereum/execution-spec-tests/releases/tag/bal%40v4.0.0

Mario Vega:Comment by Stefan: https://github.com/ethereum/pm/issues/1882#issuecomment-3798678466

Stefan Starflinger:https://github.com/ethereum/execution-apis/pull/731

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

Barnabas:Replying to "https://notes.ethere..." spec sheet for all the EIPs that we are talking about

Stefan Starflinger:we have lodestar and lighthouse CLs now

Stefan Starflinger:I'm not sure about lighthouse internals regarding this

Stefan Starflinger:Replying to "https://github.com/e..." would be good to have this merged

Mario Vega:https://github.com/ethereum/pm/issues/1882#issuecomment-3798678466

Barnabas:there are 4 EIPs not 3 Marius

Stefan Starflinger:5 with BAL

Marius van der Wijden:Oh we might not have the receipt one

Toni Wahrstätter:Replying to "Oh we might not have..." 7778?

Toni Wahrstätter:Replying to "Oh we might not have..." If so, the receipt field may be removed anyway

Barnabas:wednesday last week lol

Łukasz Rozmej:we can start devnet with 3-4 clents

Łukasz Rozmej:yeah we need to verify on eth tests

Stefan Starflinger:Since the full suite takes too long to run daily, we have created a bal-quick hive suite with only the new EIPs https://hive.ethpandaops.io/#/group/bal-quick

Stefan Starflinger:I've switched the bal hive tests to manual and the bal-quick to daily

Marius van der Wijden:Replying to "Oh we might not have..." 7708

Stefan Starflinger:sounds good

Dragan Rakita:What is better for protocol?

felipe:Replying to "What is better for..." Yeah I'm more interested in the right answer than what is easier to implement

Stefan Starflinger:We whould have 3 clients with 7778 ready without changes to the spec then?

Dragan Rakita:If this is true (you can’t get this info unless re execute), than storing it makes sense.

Barnabas:we should make a decision today imo

Łukasz Rozmej:I got lost

Marius van der Wijden:I agree we should put in the work to make it final

Łukasz Rozmej:👍

Dragan Rakita:We could do without the field in devnet-2

Jen:Reth could make it without the field in devnet-2 this week.

Marius van der Wijden:@Toni could you write it up again in discord so we make sure everyone is aligned on the same thing

Toni Wahrstätter:Here's a short sumary: https://discord.com/channels/595666850260713488/1460715235437580369/1463837761982300288

Stefan Starflinger:Then lets make the change by removing it from the receipt and try to make devnet-2 asap

Toni Wahrstätter:Here's another thread with some context on 7778: https://discord.com/channels/595666850260713488/688075293562503241/1461678093289656524

Barnabas:@James He is the beacon api question devnet 0 critical?

nflaig:@Barnabas not really, clients can implement whatever works now, we are not running mixed client setups for now I'd assume

James He:@Barnabas I don’t think so I think we are going with the 2 step process for devnet 0

Justin Traglia:Could we try to launch epbs-devnet-0 in ~10 days? I don’t feel comfortable freezing specs for devnet-1 before launching devnet-0.

James He:Btw I assume people won’t have the ptc stuff for devnet 0 right?

Justin Traglia:Replying to "Could we try to laun..." With one or two clients.

James He:Do we also have the new updated timelines for other stuff like attestations etc for devnet 0 or do we have the original timelines for devnet 0?

James He:Or is there a list of assumptions for devnet 0?

nflaig:https://github.com/ethereum/beacon-APIs/pull/552

Justin Traglia:Replying to "Or is there a list o..." https://notes.ethereum.org/@ethpandaops/epbs-devnet-0

Mario Vega:I thought NC was nico, sorry 😅

NC:Replying to "I thought NC was nic..." happens all the time haha

Eitan:Replying to "Could we try to laun…" fwiw it’ll be a stretch for LH to be ready for a devnet in 10 days. A more realistic target for us is mid to end feb

Toni Wahrstätter:Replying to "@Toni could you writ..." https://discord.com/channels/595666850260713488/688075293562503241/1465354383717040303

Justin Traglia:Replying to "Could we try to laun..." Hmm okay. According to ethpandaops, the goal is Feb 18th for devnet-0.

Barnabas:lets push this beacon api changes to devnet 1 scope, so that clients can ship faster.

Toni Wahrstätter:Replying to "@Toni could you writ..." Oh yeah! 👍🏼

James He:Replying to "Or is there a list o..." Right, I guess 7732 is probably too big to have everything by devnet 0 ( or are people aiming to have everything) I thought we wanted to do it more incrementally such as not having the ptc voting as part of devote 0

Mario Vega:Replying to "Then lets make the c..." We’ll prepare a tests release asap

Dustin:Nimbus doesn't care about the exact timeline of when the beacon API changes go in; we're using pure-BN (no separate VC) for devnet-0

nflaig:https://github.com/ethereum/beacon-APIs/pull/552

NC:I brought up the fork choice issue couple weeks ago https://discord.com/channels/595666850260713488/874767108809031740/1458127259549437992 . Sounds like it doesn’t require synchronization @Dustin

nflaig:also in general more yes on the PR would be nice

nflaig:eyes*

Dustin:Replying to "I brought up the f..." yeah looks like it can coexist

Mario Vega:https://github.com/ethereum/beacon-APIs/pull/552

nflaig:there is ongoing discussion in #apis channel so feel free to chime in there

Dustin:generically the concern is that it modifies in-production Electra/Fulu

Dustin:the question isn't whether its "tiny", it's whether it can cause consensus risks

Justin Traglia:Replying to "the question isn't w..." I’m not sure that it can cause consensus issues

Justin Traglia:Replying to "the question isn't w..." But Francesco isn’t here to give you a better answer

Dustin:ok, if there are no consensus issues, it's fine

Justin Traglia:Replying to "ok, if there are no ..." Let’s double check with Francesco. I’ll make a thread.

Justin Traglia:https://github.com/ethereum/consensus-specs/issues/4858

Barnabas:alpha 2 is aimed for epbs-devnet-1

Mario Vega:https://github.com/ethereum/pm/issues/1882#issuecomment-3791951548

Ansgar Dietrichs:EIPs proposed for inclusion in the next devnet should be posted to the ACD-T agenda ahead of time Decisions around CFI -> SFI or CFI -> DFI will not be discussed in ACD-T and should remain within ACD-E, ACD-C Is a devnet inclusion decision not basically an SFI decision?

Ansgar Dietrichs:Replying to "EIPs proposed for in..." or rather, if we end up not SFI-ing an EIP after it was included in a devnet, that was wasted effort

Barnabas:EOF was SFI-ed it can still be pulled out

Toni Wahrstätter:Clients provided great rankings and cfi'd eips should j just be included in the order based on how much support they gained.

Barnabas:CFI = have impl.

Dustin:Replying to "EOF was SFI-ed it ..." I mostly take the whole EOF saga as an indication that it was SFI'd prematurely. Of course that might otherwise happen, but it shouldn't be routine

Ansgar Dietrichs:I think it’s fine to make devnet decisions here on acdt, now that everyone is aware to pay attention here. just ideally have it clearly on the agenda ahead of time

Barnabas:if we don’t want an EIP in the protocol it shoudln’t even be cfi-ed lmao

Stefan Starflinger:A spec is never really finished until we have a working implementation

Stefan Starflinger:we shouldn't SFI a Spec we should SFI a spec + implementation

Ansgar Dietrichs:and what’s the general connection between implementation and devnet? are there usually any implementations before devnet inclusion? how easy is it to pull individual EIPs back out of a devnet?

Toni Wahrstätter:Replying to "if we don’t want an ..." That's what you might think

wolovim:psa: iterating on devnet decision making aid here: https://forkcast.org/devnets. Feedback/feature requests welcome.

Dustin:it's also how intertwined it is

Justin Florentine (Besu):and testing impact

Toni Wahrstätter:What is the conclusion now?

Ansgar Dietrichs:and (sorry last question) would it be too bureaucratic 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

Ansgar Dietrichs:Replying to "and (sorry last ques..." so we could catch EIPs that are more complex than expected

Dustin:but mostly CLs don't all have the same per-EIP modularity as ELs might have

Dustin:where they can be often granularly enabled/disabled

Toni Wahrstätter:How did we get to the 4 eips that are now added to devnet 2? Not opposed to any of them but would be good to have a clear process

Mario Vega:https://github.com/ethereum/pm/issues/1882#issuecomment-3795075740

Barnabas:Replying to "How did we get to th..." steel proposed as easy eips to have test cases out for

Dragan Rakita:In general I would really like for ACD to have a async decision making (with deadlines) this live process is chaotic.

Barnabas:Replying to "How did we get to th..." we asked ppl on acdt if anyone had any issues having these for the next devnet, no objections, so this is what we set out as a goal

Ansgar Dietrichs:Replying to "In general I would r..." you mean ACDT now or ACDC/E or all of the above?

Toni Wahrstätter:Replying to "How did we get to th..." Ok, if that's the process I'm fine with it. Doesn't need to be formalized. I trust testing and devops to have a good feeling for it. Still, the level of support should also matter.

Pooja Ranjan:https://ethereum-magicians.org/t/hardfork-meta-bpo1/27582

Dragan Rakita:Replying to "In general I would r..." I am very optimistic to say everything 😄

Ansgar Dietrichs:Replying to "In general I would r..." makes sense. agree this would be helpful, but it’s also challenging

Ansgar Dietrichs:Replying to "In general I would r..." anyway, dropping off for now. a conversation that we should continue

Dragan Rakita:Replying to "In general I would r..." I agree, hope dies last

Ansgar Dietrichs:are we waiting for someone to say goodbye?

Pooja Ranjan:I think I lost audio

Ansgar Dietrichs:Replying to "I think I lost audio" no I think people were unsure whether we were waiting for comments

Summary

8 highlights · 3 decisions · 5 action itemsExperimental

fork status and schedule

bal-devnet-2 spec tests released; clients implementing local access list00:07:09
EPBS DevNet 0 targets alpha.1 spec; timeline TBD00:52:32

testing progress

Block-level access lists restored in blockchain test v4.0.0 release00:10:49

glamsterdam eips

EIP-7778 receipt field debate: remove to simplify implementation00:24:04
Change EIP-7778 to remove receipt field; devnet-2 delayed accordingly00:35:31

epbs updates

EPBS DevNet 0 uses two-step block production process initially00:39:30
Beacon API PR 552 needs client review00:44:13

process discussion

CFI EIPs proposed for devnets must post to agenda beforehand00:55:20

Decisions

EIP-7778 removes receipt field; simplifies implementation for clients00:35:31
EPBS DevNet 0 uses two-step process; standardization deferred00:39:30
CFI status means implementation required; SFI decided in ACDE/ACDC00:59:54

Action Items

EL teams: Review execution-apis PR 731 for slot number method00:12:52
Toni: Write EIP-7778 rationale in Discord for alignment00:34:55
Testing team: Prepare tests release with 7778 receipt changes00:43:09
CL teams: Review Beacon API PR 552 for block production00:47:22
Justin: Create thread on fork choice consensus risks00:52:09

Targets

EPBS DevNet 0 - February 18th (tentative)00:40:10
EPBS alpha.2 specs freeze - February 6th; release February 13th00:52:44