All Core Devs - Testing #83

Transcript

Danceratopz: Good morning, everyone.

Berlin People: Good morning. Can you hear it? Morning! Good morning!

Louis Tsai: Good morning!

Nixo: Yes, Berlin people, we can hear you.

Danceratopz: Alright, I'll just give it a few more moments to let other people roll in.

Alright, I think we can get started. Good morning, everybody, and welcome to ACDT. It's June the 15th of 2026, and this is ACDT issue number 83. I will just drop the agenda in the chat. We've got a pretty packed agenda today. With a somewhat larger, last-minute topic emerging. About adding, builder deposit, system contracts and, and execution requests. Engine API extension. To handle that, and then we have a lot of repricing topics, which we will hand out in an EL breakout, so we're gonna have breakouts today. let's get to it. First off, I think we're gonna talk about the 80-82 proposal that was, flagged in ACDC last week. And I'll just drop some relative links in the chat for you all to have a look at.

And perhaps, is Justin in the call, and would he like to give an overview of this proposal, and say why he thinks it's necessary?

Berlin People: Sure, yeah, I am here. So 8282 is just, so it's builder execution requests. Instead of… verifying the builder deposit signatures, like, at the slot. Like, up to, like, 8,000 or even 16,000 with 400 million gas. We'd introduce a new system contract, which would work like consolidations and withdrawals. And essentially, deposits would be queued there. So we wouldn't have to do… That many signature verifications. like, per slot. Regular… validated deposits would be handled just like they are now. Maybe someone else can give more details. Like, Nico.

Nico Flaig: Yeah, I think that covers it mostly. I mean, the one thing we avoid is basically the commingling between validator and builder deposits, so you… there's a lot of scenarios where you don't need to validate the public key of a validator deposit just to check that it's not a… that the builder deposit isn't front-running that. So that's… that's the big thing there. So we avoid a lot of… there was… shared this previously, Justin has a list where there are a lot of scenarios clients need to handle, and most of them go away, with this EIP. So… and we put up, so I linked the PRs. We have the system contracts. It's mostly just a copy of the existing contracts that we already have for consolidations and withdrawals.

And then there's… Justin already did the spec PR. We did the POC in Lodestar, so it's… from the outside, it's really minimal, I would say. Maybe Justin can acknowledge that, but it's mostly wiring code from the EL, like, extending the existing execution requests. So I don't even think the effort is that big, it's just the coordination between EL and CR that's mostly the effort.

Berlin People: I agree, and I should… it's worth noting that I think 8282 is easier to implement than all of the optimizations that we would have to implement otherwise.

Danceratopz: Alright, thank you very much, Justin and Nico, for the explanation and the motivation. Terrence, did you want to add something there?

Terence Tsao: Yeah, so, I guess questions, I guess we are promoting this for, the Net Health Workforce. I, I think the CO side, I can handle it quite well. I don't really see much, like… I mean, there's complexity, but, like, it's… it's very much… doable, but on the EL side, which is… I lack knowledge on that, and, like, just question, like, how difficult it is to essentially do this right now on the EL side, meaning, like. update the system contract, making sure the system contract is right, and getting the EL support. I guess the question is, like, how aggressive can we be in that front?

Danceratopz: Thank you, Terrence. So, I think… We probably need some, feedback from the EL side about the extent of this change and the delay. Tony's asking how many delaying weeks this would approximately add to Glamsterdam. And Spencer's adding whether there was a solution without system contracts. Lewis and Spencer discussed That, in our chat, that basically, the system contract is quite complicated. And will require quite some testing in order to get that covered. So that would be the concerns from the steel side. If anyone else wants to chime in there, please do. Otherwise, I'd be very interested to hear from EL devs what they would have to say about this. Interesting.

Berlin People: I can give a quick input. So, the system contract is complex in the sense that it has a bunch of opcodes, but basically it's very, very similar to the existing system contract, so it is not like it has new logic, it's just the same type of queue that we already have. Just… With a different record size. So, is this the queue that is broken? A broken as in what? As in the fig exponential doesn't work. I am not aware of that. Like, there was this issue with the Swan system contract that you could… some requests, you could send the request, and it would only ever update the cost for the request at the end of the block. Yeah, it has this. And this is…

broken, because you can fill up the block with a bunch of requests. Yeah, this was never fixed on the original one, but it was decided that it's not a big deal for some reason. There were some arguments why this is acceptable. we could change this. It… the main reason we didn't change it last time is because we would have driven up the gas costs of adding Right now, the thing is that this… it would just mean, like, more storage writes and more computation on every single request, which just means it's more expensive to submit such a request to the chain, but… we might just be fine with that. I mean, in the end of the day, it's just the builders having to pay a bit more fee to get themselves registered in the system, so I guess that's acceptable. But it does mean we would have to apply changes to the contract and also re-verify the contract, so yeah, that's…

something to keep in mind. But I don't think, fundamentally, this contract is very complicated. It's just a queue storing stuff to the storage, and we have to… Check it, but, you know.

Danceratopz: Alright, thank you, Felix, for the input. Would anyone else like to speak up from Execution layer clients? Respectively, I see that Tony mentioned in the chat that we're going to need one solution or the other, and that this does feel like a right solution. Tony, did you want to elaborate in the call?

Toni Wahrstätter: I don't really have that much to say. I very much agree with what Justin said. It feels like splitting builders from validators. solves the problem. Of course, we have to also bump the SSZ limit for validators, in parallel, but this is… this should be easily doable. And it allows us to scale up, beyond 190 million. So, to me, it feels like this is the… The best solution we have right now.

Danceratopz: Okay, perfect. Thanks a lot, Tony. So I think… most people seem… I mean, the people that have spoken up seem to think this is a reasonable change, and that, it does seem to make sense to do that for Glamsterdam. The main motivation of this discussion is really just to try and get rough consensus so that we can ratify the decision in ACDE on Thursday. In the meantime. On the steel side, we can make a better effort at estimating the testing cost as we see it. Does anyone else want to… Add anything to this topic? Before we go to the DevNet discussion, sorry.

Enrico Del Fante: I just want to ask one thing. So, to me, this makes, sense, and this is the cleanest solution, seems like. So, on the, performance issue that, we had on the processing of the signatures from the CL site. I was wondering if is… is… any client has its own problems, and are we… are we… do we agree that there is no perfect solution if we don't adopt this, and there will be, anyway, a DOS vector potential for any possible So it's actually impossible to have a client that perfectly handles the edge cases. Because I feel like tech is… we are improving and making our… our validation faster, but I heard that Prysm is doing a better job compared to us, but I feel like Prysm has its own

Potential issues anyway. So… Yeah.

Danceratopz: Terrence?

Terence Tsao: I think I can speak on that. So, I think we can handle all the cases, except the cases that, like, the attackers are willing to, like, burn, like. lots of ETH. I'm speaking on the scale of, like, thousands of ETH, right? But in that case, like, the question is, like, what's the difference with the attacker doing that versus, like, the attacker just buys empty block and starts spending them? So, like, I guess the fundamental question is that, like, what is the economic modeling we are willing to accept here, right? I mean, like, a lot of the attack that we are testing make it up here. may not just be… I mean… I mean… I mean, like, I mean, it is realistic on mainnet, but the attacker has… has a… has a cost to such an attack.

Enrico Del Fante: I… I see, so probably the good… the correct framing is… mostly simplicity, because having this, this solution, you don't need to think about Those cases, and you don't need to add a special, optimization for handling this condition to make this thing behave like an… It can ramp up these conditions into economically feasible things. So… Maybe if we had designed this from the beginning, assuming more time, we could… we would have landed in this situation… in this solution anyway. And it… just because it's… The most natural things to do.

Danceratopz: Thanks a lot, Terence and Enrico for the… for the thoughts on that. I agree, it does seem like the clean solution. Berlin people, would you like to speak up?

Berlin People: Oh yeah, that's me. One more thing to mention is that… Prysm can, like, handle the case where it's… the gas limit's $200 million, but it might not be able to handle the… When the gas limit's, like, 400 million, because the… Number of builder deposits you would be able to submit per slot would double. I'm just saying, it'll be more difficult as the gas limit. is raised.

Danceratopz: So, sorry, can you just say it… say again, Justin? So basically, with the current gas limit, it's not really an issue, but as the grass limit increases.

Berlin People: Oh, I'm saying that we did all of our testing with, like, 193 million guests, like, the current, limit within the SFC limit. But, Meaning that we only tested where, like, per slot, the maximum was, like, 8,000 new builder deposits per slot. Someone could submit… A transaction with 16,000 builder deposits in a single spot, and that would probably cause a bunch of issues.

Danceratopz: Okay. So this is… this attack is basically a 16,000 ETH attack per slot, right? Is that correct?

Berlin People: No, I'm just saying that it depends on the gas limit. Like, it gets worse as the gas limit is raised, is all.

Danceratopz: Got it, okay, yeah, thanks. Tony?

Toni Wahrstätter: Yeah, does the attacker cost also get worse with the gas limit? Because this is then, like, going back to what Terrence was saying, like, I think this was an actual very good point, that what is the risk we are taking here? If someone would actually submit that many deposits, are we risking a few missed slots? Which, Terrence is right, if you have that money to attack, you can just literally buy empty blocks.

Danceratopz: Maybe Potuz has the answer? Did you want to bring up another topic?

Potuz: No, it's on the same topic, but it's not an answer to that. But, I mean, if you want an answer to that, no, the attack is about… the worst kind of attack is you upfront a lot of money. You spend a lot of money, and then you keep the attack by just sending a single transaction per block. So the cost is just the upfront that you have. as long as you upfront enough money that no CL client can handle that blog, then you're good. And that implies that no client will have a cache, but what I want to stress out is that perhaps this discussion would be better taken in a different setting. Instead of, like, talking about this particular attack.

I think it makes more sense, at least to me, to decide whether or not we want to have this solution, we want to have this design or not. The design seems, completely reasonable to me. It should have been the right design from the beginning. For the way Ethereum governance works, this could not have been proposed with the IP, but it's clearly the right way of doing things. It removes an attack from the consensus layer. And this is the clean design. This is the right solution. And not for this problem. This is just the right design, to have these two paths separated. Now… If you want to conflate this with this attack, I think we're just wasting time thinking on this particular attack. This attack is not really an attack.

We already have much, much worse ways of causing liveness issues on Ethereum. We're talking about up-fronting money enough to buy the next 20 years of worth of blocks. And I kid you not, just do the arithmetics. And… and as… for each block that passes, we only need one player to submit a block that is actually executable. or one player to wait until the blocks are executed, and that's it. The chain recovers, and the attacker lost all of their funds for 19 years worth of blocks. So this is an attack that we're just wasting time arguing about. We should phrase the discussion on whether or not we want this design or not, in which case, I think this is the right design, and I think no one here disagrees with this statement. The disagreement might be on whether or not we want to put the time, we want to delay the fork, this will delay the fork.

It's false that we would need more time to implement the mitigations. The mitigations took less than a couple of days, Terence, to implement on Prysm. So, it's a reality. We are going to delay the fork, because it needs coordination across different layers, testing the EL and the CL, we're going to change the API. The question is, do we want to do this right now or not? It's not a question about this particular attack.

Danceratopz: Thanks a lot, Potuz, for the perspective. Yeah. I think that makes a lot of sense. About the time discussion? These contracts will need to be audited. as brought up by, Justin in the chat, and… That is probably one of the factors which will cause the largest delay, to glamsterdam, but not necessarily for definite testing. That can be done in parallel. Is… is anyone against, just to get a temperature check, is anyone really against, making this change? would people prefer correctness in Glamsterdam over Delane? Okay. then… I would say that we're in quite a good position for… to make a decision in ACDE.

On Thursday. But just before we move on to the definite discussion, people are chiming in with correctness in the chat, which is… Obviously, the correct answer. But just before we move on, is there anything we need to do, or in the mean, before with Thursday, in order to expedite this? Is there something that we need to know or prepare, before Thursday? Nico?

Nico Flaig: Yeah, just one thing to point out, because I'm not sure, how this can be done, but… so we will deploy the contract before the fork, I'm guessing, and then, there's the scenario where you already have builder deposits coming in, so I'm… curious how the EL would handle that, because I think there was an idea from Potuz in the chat in ePBS, I think, where there was a mention we could use this mechanism to onboard builders at the fork, but I don't think, that works. to do at the fore, but just curious if ELs can take a look at this, and… Yeah, just think about how that could work.

Danceratopz: That's a good point, Nico, thank you very much. Does… Someone have an answer on the spot for that now, or any… any thoughts on that that they want to bring up? Okay, then that's definitely something we can pick up for ACDE on Thursday. Otherwise, yeah, please put your thinking caps on and comment on the ACDE issue, if you have any other reservations or… what we… what we need to do? Potuz?

Potuz: Yeah, so this is not something to take lightly, what Nico just said. One of the arguments to ship this EIP is to prevent having cached on clients, but clients will need a cache to deal with the fork. Even with the CIP, unless we change that. So, DCIP is not preventing a cache that we need to handle at the fork. You need to validate the signatures of the pending queue of deposits at the fork, otherwise you're also not… you're gonna be facing the exact same attack, just at the fork.

Danceratopz: Thank you, Potuz Dragan.

Dragan Rakita: A different topic. If the CL is going to take additional 3 months. Let's ship EL before that. We are kinda at the finishing line on the EL changes, and we don't have a lot to do there. We are basically… we'll be ready in, like, a few months, that's… Assumption here, and… The best guess. So we could ship CL without CL, and then CL can have its own fork. In, yeah, January, February, whatever.

Berlin People: Well, but…

Dragan Rakita: It is.

Berlin People: this… this thing impacts CEL, right? Oh. Well, we need to ship the contracts, and And we cannot increase the gas limit unless we have this.

Dragan Rakita: You can increase gas limit by some amount, because the split between the state gas and the regular gas is basically there. I do agree that probably you cannot ship it, increase it by… like, 5 times that we, like, want to do, but you can at least do something, basically unblock EL from CL in this form.

Berlin People: Yeah, PK calculated that, I think, and what he ended up with is, like, you can do a bit more than 200, If, with 8037, or, like, the, the gas changes and… Yep.

Dragan Rakita: Yeah, we cannot… we don't even need to, like, go to 200, we can go to, like. 100. That would be, like, big bump, and we will have all… all the things that we are basically working on will be basically deployed. I think it's a good idea if, basically, CL needs more time. But yeah, this is, like, for discussion for all code devs.

Danceratopz: Okay, yeah, thanks, Dragan. Perhaps… this can be discussed async in the meantime before Thursday, if people have strong thoughts on that, and then we reconvene on Thursday to discuss that aspect. Potuz?

Potuz: Yeah, probably we have a disagreement with Maria's that's talking about numbers, but I think you guys are out of your head. Balls would increase the block size between 50% and 100%, And even at today's block sizes. And it's not what we're going to be broadcasting just the CL block, we're going to continue broadcasting the full block. Today, we have 2 seconds for both propagations and execution. If we increase the gas limit, we're still going to be working on that. the same 2 seconds for propagation plus execution, and on top of that, we're going to be broadcasting a block that is not 90% smaller, it's going to be twice as large as today. So I think it's just crazy to try to ship any gas limit now without ePBS.

Danceratopz: Thank you, Potuz. Yeah, I mean… The other… on the other side, the other question that Terrence raises is, would this really delay ePBS by 3 months? And, yeah, that's…

Berlin People: Sorry, porters, I don't really get it. Why can we not just increase the gas limit? The… Yes, the payload will be roughly 2X of what we have right now, but we still have 3 seconds. We're targeting…

Potuz: No, you shouldn't be targeting 3 seconds. We don't have 3 seconds today.

Berlin People: That's including timing games, quotas, but timing games is elastic demand. If the block is bigger, they don't want it orphaned, so they reduce the amount of timing games.

Potuz: I think now you're talking about something that we don't understand. I mean, why the blocks would be bigger if I can extract more MEV by delaying the block auction?

Berlin People: Sure.

Potuz: This is out of our hands.

Berlin People: Okay, but we're still targeting about 100 megas… 100 million gas per second from benchmarking and ring pricing. So even assuming 2 seconds, that means we should be able to handle 200 million blocks, and let's forget even that, let's just increase the gas limit to.

Potuz: That again, that again is without the propagation. So it's not about execution, it's execution plus propagation. We don't get the decoupling if we don't ship ePBS.

Berlin People: Yeah, but don't… Don't need it for smaller gas increases, is the claim. There's a lot of things happening in lock-level access lists and repricing that has other benefits besides just increasing the gas lift. Don't we have, like, 4 seconds for… until attestation deadline right now?

Potuz: Well, but… That's not what's happening in reality. We have 2 seconds. The blocks are coming after 2 seconds.

Berlin People: Beautiful. Yeah, and then you'.

Dragan Rakita: I've done a…

Berlin People: Good weekend.

Dragan Rakita: We can… we can even be real, like, conservative and just leave it at 50 million increase, and even if that's not enough, we can decrease it at 20 million for a few months until, like, CL. comes. But I don't see the point, basically, that we need… we need ePBS to increase the gas For any match. Even if block is bigger, there's a lot of time to, like, propagate and everything to do.

Berlin People: There's maybe an additional point. Even if we don't increase the gas limit, repricing and block-level access lists stand on their own. They're still good features to ship. It reduces the amount of computation a node has to do, it makes ZK proving easier, there's a lot of other topics in there, even if we don't touch the gas limit.

Danceratopz: Alright, thanks a lot, everyone, for the debate and expressing your opinions on that. I don't think we're gonna get to a conclusion on that today. That's something that we can follow up on Thursday. Perhaps… someone… we can make a proposal on Thursday for the two routes? Obviously splitting the… EL and CL at this stage is, it's quite a big change. Barnabas, did you have something to say on that?

Barnabas Busa: Yeah, so there's still proposals in changing AD37, as of today, so… saying that the EL is, right at the finish line is maybe… Yeah. Not quite right yet. So I, I would just… I would still default to shipping ePBS with Amsterdam, for now, and… really only if the ELs feel like they're like, being, Hardpacked by literally multiple months of, shipping, where I would consider splitting out the two.

Dragan Rakita: Just to add to that.

Barnabas Busa: The government has more chaos.

Dragan Rakita: we from EL side, we are planning, just one additional DevNet. And we are finished with all the changes. There are a few padding things, yes, that's correct, but that is for the last demo that we planned. This is not months of the work. This is something that's going to happen in the next few weeks. Just, like, information.

Danceratopz: Thanks, Barnabas. Thanks, Dragan. just to talk about DevNets, basically, I mean, before 8282 came up, the plan was to launch Glamsterdam DevNet 6. Bal DevNet 7 is ongoing. Glamsterdam DevNet 5 is also ongoing, there was an issue there, but the net has been rescued, so the next, canonical Glamsterdam DevNet would be DevNet 6, and that was initially the target for the larger EL EIP. changes to get in. The new… the remaining repricing EIPs, the removal of the self-destruct Burn EIP, and and some other, spec changes across a couple of other EIPs. So, I think… regardless of this larger discussion, that would be still the plan. that makes sense, at least to me. Happy to hear other opinions.

And then an 8282 DevNet, or 8282 could be added to the subsequent DevNet from that. Otherwise, I don't know if it makes a lot of sense to go into definite planning detail right now, since we have, much bigger discussions in the air. I would… consider sandboxing this for now, as we have to move to the breakouts in a few minutes. Is there anyone who wanted to add something? Before we move on, something that would still be relevant to know now before Thursday?

Berlin People: Yep, sorry, the, REST SSZ, maybe, because that is, impacting both layers. We have some changes to the spec. There's implementations in… At least 3 clients now, so, Yeah, it would be… what's really missing, I think, is a CL to… to really implement this, so we can start doing some testing. But, yeah, this is kind of… it's not really fork work, so it's kind of… I don't… I don't want to take off too many resources from… from things that are more pressing, so, yeah, once… I would hope once we are on, on tests, on the first testnets, or on, on, like, the last dev nets, we can put more resources onto shipping this thing.

June? Yoon?

Jun Song: Yeah, so, I guess Prysm is almost ready for, testing. One thing I have to, do more is the, the SSZ format of request and response that, we, wrap entries as SSZ containers, but, currently Prysm follows what Erigon and, ethrex, did a few days ago. So, yeah, I guess that's only one more commit. are needed to, communicate with gas and the spec right now.

Danceratopz: Thanks for the update, June. Marius, to your… yeah, we didn't… I didn't want to forget that for the breakout. A quick question is, What is it that you need on your PR to get it over the edge? I'll drop a link in the chat. This is the execution APIs PR793. I think you're… you would need some reviews on that, right? It's not good.

Berlin People: Yeah, there are multiple implementations, and based on those implementations and the reviews from that, I did change the spec again, so everyone should Review the spec again, and see if, and also adapt their implementations to the new spec, which… for example, contains what, June just said, the, the, the change that we are, packing, the… well, like, an outer layer of SSZ packing, and so, yeah, just look at it. Again, I don't want to take too many resources away from the fork, so… It is not super high priority right now.

Danceratopz: Okay, thank you, Marius. It looks like Andrew left a question on the PR, following from your comment yesterday. And otherwise, I think, Lukash… And I think Yasik, You asked them to have a quick look at it. Okay, thanks a lot, Maris. Alright, just before we move to the breakouts, I think those were the last topics, I just wondered if someone wanted to give a quick update for everyone what the situation was on DevNet 5? And whether there's, any, any vague sort of idea about the timeline for DevNet 6? Does someone want to give an update on DevNet 5 quickly? Glamsterdam DevNet 5?

Barnabas Busa: Yeah, sure. Definitely 5 has been sort of stable. Prysm been having some peering issues, and also Grandinee had, some issues, I'm not sure if anyone from Grandine and Prysm could speak up of what the issues were.

Saulius Grigaitis: On Grandinee's side, we had a few, bugs, and I think we're still fixing some edge cases, so yeah.

Barnabas Busa: Yeah, and I think from Prysm side, it was a peering-related bug.

Potuz: It's… it's not clear. There's a conflict… I mean, there are a bunch of things that are coming together. For some reason, we're not getting DA on time over gossip. So whenever we can recover the blobs from the EL, we just sync the blob quickly, and that's it. But from time to time, we do not get enough data columns of our gossip. We request them, we get them from the peers, and we sync the block, and sometimes we are in that path, and the peer doesn't reply with the data columns, and then we're stuck. So then we go back to initial sync. So that's one bug that we do not know what it is, we do not know if it's our bug or if it's just peering, but we're not getting the data columns of our gossip from time to time.

So we fall back to initial sync because we… we can't sync those blocks, and on initial sync, we seem to be having a different bug, in which we request columns for blocks that weren't canonical. And then peers just… reply saying we… we don't have them. And that's… that's definitely our bug. We're requesting columns that we shouldn't be requesting.

Danceratopz: Okay, thanks for the updates. I think we should probably go light on the details here, because we need to move to the breakouts any minute now. Glamsterdam DevNet6, I'm guessing that this will be a topic for next week, but, I think on the steel side, we still need time to, to… so I can drop the tracker. We have a tracker for, DevNet 6. And, I should think we probably need at least the rest of this week, and probably early next week to get ready. I don't know if anyone else from the team wants to jump in there. Or does anyone have any ambition of when this devnet should be launched?

Barnabas Busa: Do we have data spaces for, all the remaining EIPs?

Danceratopz: No, ex… no, we do not.

Barnabas Busa: Okay.

Danceratopz: He brought up.

Barnabas Busa: What was the timeline for that?

Danceratopz: I would say at least, this week, Spencer's aiming for next Monday.

Barnabas Busa: Okay. Then I would suggest, next Wednesday?

Potuz: Amsterdam DevNet?

Barnabas Busa: Yep.

Potuz: What is the change on the… on the CL side?

Danceratopz: Let me drop… On the EL side, sorry? Or on the EL side?

Potuz: On the CL side, is there any braking change? Is there any change?

Barnabas Busa: No.

Potuz: then why are we going to do a new glamster than DevNets? I mean, you can just deal with this on the Yale DevNets.

Danceratopz: to test the integration, I guess?

Barnabas Busa: Yeah. But if it's no changes on the CF…

Potuz: side, then that can be handled completely on an EL DevNet.

Stefan Starflinger: When we merge them together, there is no ELDF notes. That's the idea, to keep everything attached to them.

Danceratopz: I'm sorry, Stefan, but you're a bit…

Potuz: Yeah, that we're merging them, but… but aren't there, like, ball dev nets?

Dragan Rakita: Potuz, we basically… Finishing up the work, and basically, we don't have a lot of changes that we want, new changes or big changes that we want to push on the separate debit. That's why the reason was to merge those. Because, as I said previously, ELside is kind of finalizing things. So we don't have a lot of big change that we expect. But if we wait…

Potuz: If we wait, say, just a couple of days more, then we… I mean, we are now at Monday. If we just ship it instead of this Wednesday, we ship it next Monday, we can do also a, we can also do these requests, and then test the full sale.

Barnabas Busa: The target is next week, Wednesday, not this Wednesday.

Potuz: Oh, next week's Wednesday, yeah, we can… then probably we should add also, I mean, if it's agreed that we're gonna go with the new request, we can just start testing that.

Barnabas Busa: I mean, we were, yeah. I think we already agreed to ship 828, too, right?

Danceratopz: I mean, pending disc… pending a decision in ACD on Thursday, I think pretty… people are pretty much keen to get it shipped, yeah. But I would… I mean, I would just add quickly, sorry, that I think the 8282 on top of the other EL changes is probably a bit heavy for the next devnet. If anyone else wants to chime in, but that would be my feeling.

Potuz: I don't know, on the CL side, I think even without merging the PR, it should be simple.

Danceratopz: Mario?

Mario Vega: I think we can basically just, take the template for the previous test for the system contracts, and we can… Yeah, I do agree that we should, like, put 8282 in the statement.

Berlin People: Implementation? Yep. on the… guest site, should only take, like, I don't know, a day or at least, because the… we have the… the same structure for the other contracts. So we just need to pass the, pass the logs and… and figure out what… what was happening. So, yeah, the big thing for 8282 is… is the… the reviews by… by some security people.

Danceratopz: Okay, I like it, I hear the ambition. then it looks like we'll try and get 8282 in the next step now as well. Alright, then, Spencer…

Potuz: on the engine API, then? Someone needs to put up a PR for the engine API changes, or is it already in the AIP?

Berlin People: There are no API changes in this. Right?

Potuz: What do you mean? We have new requests.

Berlin People: Yeah, but the requests are generic. That's… you don't have to specify it, you just receive those requests alongside all the… that's the whole point of the.

Potuz: Oh, so we just changed the prefix, okay, that's perfect.

Berlin People: it just adds another type of request, but that doesn't have to be specified. That was why we added the generic mechanism.

Danceratopz: Alright. Okay. Thanks everyone for chiming in on that. It looks like we're upping the ante for Glamsterdam Definite 6. Let's take the conversation about the changes required to async. And then I would ask if someone with magic breakout capabilities could create the breakout rooms. Is there someone here who can create breakout rooms? Is, Barnabas or Pari, can you do it? Or can Mark maybe do it?

Barnabas Busa: It should be done.

Danceratopz: Amazing. Thank you very much. Thanks a lot, everyone. See you on Thursday, respectively, next week.

Barnabas Busa: If someone's having issues, getting themselves assigned, let me know. Is anyone still struggling to get, into their breakout room?

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