All Core Devs - Testing #63

Transcript

Spencer Taylor-Brown: Hello!

Mario Vega: He's better.

Fredrik Svantes: Hello?

Mario Vega: Hey. Let's just give one more minute, and we can start.

I think we can start.

Akash | ECH: We are live.

Mario Vega: Thank you, Akash. Good day, everyone. Welcome to ACDT number 63. Today is December 8th, 2025. We have a very light agenda, but the… I think the most important discussion point is that, Fusaka Fork happened last week, and went well. But yeah, for the first point, I would like to start with… yeah, congratulations, everyone. For the first point, I would like to touch upon the events that happened, if… anyone from any team, I think Prysm is one of the ones that wants to share more in this section. Is anyone from Prysm here? Should we start with them? If not, Barnabas, do you have, any events that happened during the fork that are important and meaningful that we should share?

Barnabas Busa: Yeah, so Prysm attestations came in a bit late, and this ended up in a cascading effect. They had a flag to fix the issue, that was already included in their latest release in 7.0.0, and they said that they would push out a proper fix, sometime today. I haven't heard anything from them since, but hoping in a new Prysm release for Early this week, but ideally by end of today.

Mario Vega: Alright, thanks. Yeah, I think we can give some time from someone to present to you, if they want to expand. From any other teams, do we have any important events that are worth sharing here? Findings, or reports, bugs found? Anything?

Bharath Vedartham: Yeah, I mean, I can share one thing, so… I don't think there's any impact in this, but, one of the things… this is through going through the Titan relays, GitHub, I noticed that… so we introduced a Get Payload V2 for Fusaka. I noticed they have a bug fix where we didn't… where they didn't add it… add it to the routes. like, basically, like, they didn't add it to their API routes. That would ideally have caused, like, payload… the API not found, but I think, luckily, we had, Fallbacks in both commit boost and ref boost to, like, avoid this. So, I just thought, like, that's something kind of notable, but I… there wasn't, like, any impact

on that, as far as I'm aware, like… So, yeah, I think if that… the fallbacks weren't there, there would have been a bunch of missed slots, so… But, yeah, but I wanted to, like, point that out.

Mario Vega: Thank you. Was there any impact on network stability that was worth sharing, or… Wasn't you… wasn't not noticeable.

Bharath Vedartham: Oh, no, on the Get Payload V2, there was an impact, because the client's MevBoost and CommitBoost both implement, like, fallback, so when we call V2 and it's not there, we fall back to, like, the V1 API. So, the V1 API hash is definitely… has to be implemented, otherwise the relay wouldn't be alive. So, So yeah, so there wasn't, like, any impact, because we also noticed no, like, missed slots in that aspect. There was no impact on that, and Yeah, but it was something, like, worth, like, just bringing out and, like, letting you guys know.

Mario Vega: Thank you. Thank you. Cool. Any… any other findings or comments from other client teams that is worth sharing in this meeting? Alright, I think… I think not. That's… that's actually good. I see a comment from the peer-to-peer team, no, sorry, for Barnabas, Raul, do you want to expand? I see you also commented on this.

Raúl Kripalani: Yeah, yeah, yeah. So, I just wanted to give a short update on some data we've been collecting from Mainnet in preparation for BP01, just to kind of, like, maybe give a bird's-eye view of how things are progressing, and what we've seen, and maybe some recommendations. Not necessarily for BPO1, which is coming tomorrow, but for next BPO upgrades. Is it okay if I share my screen?

Mario Vega: Yeah, absolutely.

Raúl Kripalani: Absolutely. Very cool. Let me, get this ready. So, what… the link that Barnabas shared is actually from a small set of notebooks that we're putting together, and this is going to be enhanced over the next few days. We're hoping to basically get different perspectives and vantage points into the network from different, areas to kind of, like, keep tabs on how things are going. So, the first notebook that I wanted to show here is, one that shows blob inclusion, so that's basically the patterns that we're seeing in terms of how many blocks, were, including how many blobs over time, and you can see that, kind of like the most popular ones, the most popular blob counts are 9, which means that we are obviously at, like, almost, saturation right now. Then you do see some, some density, some more density on 6,

3 and 0. Some blobs, some blobs didn't include any blobs, we'll… we'll touch on that briefly now. This is another similar view, but this is breaking it down by epoch, so you can see kind of, like, a little bit of a flame graph-ish view on how many blobs were How many blocks included how many blobs? In a particular epoch, and you can see some interesting patterns here, like, for example, there was an epoch that included a high rate of, of, blocks with no blobs. Sorry, I don't know why I can't zoom in here. Other graphs allow me to zoom in, but not this one. So this one, and then kind of like the next epochs actually compensated for that by stretching and including 9 blobs. So we see that elasticity in the mempool, and that elasticity in

inclusion, which is great. We see the same pattern here again. We're actually investigating exactly what might have happened here. They were kind of like a sequence of 9 or 7 blocks, I think, that were… that didn't include any blobs. So we're actually, you know, finding patterns here and then doing deep dives, so I'll probably have another further update to share at another point. This is a pivoted view of the same thing, but this is, showing, yeah, just, just a different view, where we see that, exactly that, that pattern. So, what we see here is that. Yeah, so most, We… we're actually seeing blobs included, and especially kind of, like, a high rate in the… in the, edge saturation there, the max blobs.

Sorry, that went out. And then, these are some other views. These are, like, maybe some visual… more visual candy. This is one… actually, let me go into column propagation, because this is the first one that I wanted to point out some patterns on. So what we see here is, basically a… all this data that I'm showing you is just from yesterday. These notebooks are going to be regenerated on a daily basis, and we'll probably add, more, longer periods and longer views, so that we can keep tabs on, kind of like, you know, the evolution side of things. And what we see here is, for… rows are columns. And these correspond to column subnets, and then this is the passage of time, and we're actually plotting for every slot, when do we see the first column? Sorry, when do we see the first copy of each column?

So you can see some very interesting patterns here, where you see that there's actually a lot of similarity. If you look at the Z value here as I'm scrolling, as I'm moving my mouse down, you see that that is actually changing on a per column basis. Sorry, I just moved across slots, so you saw it change more than it does within a slot. But you see there, like, the moment that we see a first column, we're basically, like, practically seeing all other… all other columns, at the same time. This data, by the way, is collected from, ETH PandaOps' Shattoo deployment. We need to qualify it a little bit better, because there's a mixture of nodes, so different nodes might be seeing different things.

And of course, we're plotting the min for every column here, so there might be some adjustment that's needed here. But yeah, some interesting bits is that we do have some slots where, for example, the first column, the first copy of every column was seen, kind of like. 200 milliseconds before the attestation deadline, and this is, like, starts to be problematic. We need to correlate this with blob count and a bunch of other things, so, so, it's again, like, this will be enhanced. But yeah, you see, kind of, like, when the first column is seen, then the rest of the columns are practically seen at the same time. This is a similar graph, but more sensitive. This is actually computing the interest lot delta from the fastest column.

And plotting it in milliseconds. This… the timescale is… so you see the sensitivity here? Like, practically… once we see the first column, all of the columns are seen, like, within 250 milliseconds, which confirms this sort of pattern here. But what I found interesting is this one. Delta normalized is just… so this is in millisecond terms, and this would be in percent terms, so basically. If 0 is the slow… is the fastest column and 1 is the slowest column, then what is the pattern that we're seeing here? And you see that in general, like, we see some banding, which is very interesting, so we see that… The first columns are actually seen sooner, so, and this makes sense, because clients are probably, blog builders, sorry, blog builders are probably…

Pushing columns sequentially through the network, starting from zero and then progressing up until 127, zero indexed. And… And yeah, so we see more… so these are the first columns that we see, but then we see some banding as well, which is very interesting. We're investigating where this is coming from, because it doesn't necessarily come from, like, you know, binary, like, indices or anything like that, so it might just be that the subnets behind… The meshes behind these custody subnets are actually stronger, or are better resourced, but you do see, like. some… some stepping there, which is very interesting. So we're trying to, like, dig into… into that, and I think we'll have some… some data. And then the one that Barnabas,

deep link to is the… the blob flow. So we're… we've charted, once again, using shadow data, which is super, super helpful, which also pulls for meats here. We are seeing, what we see here is which proposers are… proposer entities are including how many… how many blobs. This is a direct relationship between proposers and number of blobs, and then, relays to blob counts, so we wanted to check, is there a pattern? Are some relays including, like, you know, favoring blobs or, like, specific block counts or not? we just see, kind of, like, for reference purposes, a proposer-to-entity relay, so we see, like, which proposers… proposer entities are using which relays, and then finally, I think this, like, puts everything together. This will be the most interesting one, out of here, that kind of, like.

connects all the dots across the board. There's really, like, the spread is pretty… uniform. Not uniform, but I would say, like, there's no pattern that really stands out here, except for, one that I pointed out to the flashbots, people, which is we do see that they're, proportionally to the amount of blocks that they, that they relay. they have a larger, like, they, they are above average in zero blobs, essentially. That's kind of, like, the one thing that stood out. So yeah, having done that, that overview, very brief overview, I do want to go, I wanted to go back to the column propagation one. Because this pattern is denoting that we're… that there's some room for optimization in dispatching quantums to the network, and I wanted to propose… what I wanted to propose to CLs here is there was an optimization that we shipped, a few months back.

Which is, in Gossip Tub, it is a… What we called batch publish, but essentially this is a breadth-first policy for getting columns out. as a builder, or as a node that happens to have those columns… that happens to have all blobs, and therefore you can source them from get blobs, and you're able to publish the message in the first place, so you don't even need to wait for the builder's propagation. So, in these two cases, it's gonna help to do a breadth-first dispatch. So that is, with batch publish, we're giving 128 columns directly to Gossip Sub, and then today, most implementations, if they don't use breadth-first dispatch. What they're gonna do is they're gonna prioritize, sending all 6 or 8, or 10 copies, or whatever the mesh degree is, for every column… for every column.

First, and then they would move on to the next column, and so on, and so on, and that could be justifying the pattern that we see here. So with best breath-first dispatch. What we'd be doing is basically prioritizing sending, like, at least two copies of each column first, and then we continue deepening the replication in each… the redundancy in each subnet. So that would be one of the things that we propose. This is already implemented in Go Gossip Sub, so for the Prysm team, it's going to be quite easy to adopt once they upgrade Gossip Sub. I heard from Joao and others that maybe it's not needed in Lighthouse, but I wanted to double-click on that, and then wanted to check with other teams as well. Of course, this is, like, this change would not be consensus-breaking in any way, it's just a network optimization.

So, I'll stop sharing there, and just wait for any questions.

Mario Vega: Thank you so much. Any questions on this? I think we… since this was a little bit impromptu, we might need to revisit the topic also in ACDC, if possible, just to check if anyone is missing from this conversation, they should be aware of it on ACDC. But yeah, Pawan?

Pawan Dhananjay: Yeah, hi, quick question, did you also measure anything with… related to get blobs effectiveness? Like, are we still seeing private blobs at all, or.

Raúl Kripalani: Yeah.

Pawan Dhananjay: Yeah, just wanted to see if there's any difference between.

Raúl Kripalani: Yeah.

Pawan Dhananjay: Cop.

Raúl Kripalani: Yeah, yeah, yeah. That's a great question. Actually, we need to correlate this data with precisely presence of blobs in the mempool. with missed slots, and with a bunch of other things that we have in mind, so not yet, but hopefully by today or tomorrow, we'll be having that correlation, and I'm happy to send people a link in Discord.

Mario Vega: Cool, any other questions? Alright, I think not, amazing presentation, Raul. Thank you so much for sharing. Alright, so, circling back, to Fusaka, because I see that someone from Prysm joined. Is a… is a… Who was it? James. Yeah, James from Prysm, do you have any… because we touched upon the topic of Fusaka at first, and I think Prysm would like to, if they have any updates to, the events that happened during Maynet, so, just wanted to chime in to see if you have any… any updates on that, or anyone else from Prysm, if they're listening.

James He: Yeah, I guess we're trying to do another release with a more permanent fix. Hopefully that comes out today, if not the next few days. And, POTUS is also helping write up a technical post-mortem, and we'll have, like, a more official post-mortem, as, as well. And the new release will have a backfill in it.

Mario Vega: Excellent, thank you. Thank you for the update. Alright, Alright, so yeah, with Fusaka out of the door, we have also BPO Fork number 1 happening tomorrow, in less than… Exactly 24 hours, almost. I just wanted to bring up the topic to see if anyone had any, necessary comments on this, are we good to go? Or any concerns, that can be raised? At this point. Yeah, I guess not much to say on that topic. We will monitor the chain tomorrow when the fork happens, and… Stay in the comps to see, that everything goes smoothly. Alright, With that, any other topics on Fusaka, or any other comments on Fusaka that anyone wants to share today?

If not, we can go directly to Glamsterdam. Yeah, alright, so the first topic in the agenda for Amsterdam is… Amsterdam is, block-level access list. Do we have anyone in the call that would like to share some updates on this?

Stefan Starflinger: I can maybe start out giving some updates from our side. So we've been running the Kurtosis testnets a lot, and I managed to get a new milestone of 13 epochs running with 4 clients, which is the most we've done so far, so that's pretty nice. Otherwise, I think Nethermind has now also added the debug endpoint. I will share, kind of, the link. in the chat, if clients, can, if possible, add the debug endpoint, update the debug bad blocks endpoint to add the generated block accesses, that would be great, so it's easier to debug. I think we have now Nethermine and Bezo that have it. Otherwise, we've been finding still quite a few issues in the kurtosis network, so we would recommend the clients all

run with the EVM fuzzer still to see if there are any issues with their clients. I think that's the easiest way, kind of, to figure out if there are any inconsistencies still. Even if you pass all the tests, we're still finding some issues. For example, a recent one, maybe Felipe can talk about it more also. If you're on the call, About, kind of, some of the tests that you've been working on? And that will be in the next release.

Felipe Selmo: Yeah, sure. Yeah, we've, we've been finding, basically, gas boundary issues in… I think you found one, Stefan. With, self-destruct. And so we've been working on adding, tests around, Checking gas before account excesses, all throughout, The spec where this is found. And right now, we have, I would say, probably one or two new cases of this, and we already had quite a few in the last releases. But we hope to get these reviewed… And merged in and released, early this week. for clients to be testing against. And anything that we're finding in kurtosis, we've been trying to write tests for as well. Although sometimes, without these Debug endpoints, they're not as easy to find, so these would help quite a bit.

Stefan Starflinger: Yeah, and also, I think most clients now have it in their logging, when there is a disagreement that you log either just the minimal div, or just log the whole log-level access list, so it's easier in the tests and also in the kurtosis networks to see what is the difference. That's been very nice. And, like, my goal would be to start a DevNet. I've actually already, accidentally started DevNet. But I can't really run any load on it, because it will, basically, fall apart pretty quickly. So, we will probably start DevNet1 once, Kurtosis is running for at least 24 hours, with at least 3 clients. that's kind of the benchmark where I would like to start, like, a proper definite.

I think that's pretty much it from… from my side. And we… One more update we've added in was… yeah, it's caught up with most of the log-level access lists, so that's pretty nice. Tests.

Mario Vega: Excellent. Thanks so much. Yeah. Yeah, yeah, please, go ahead.

raxhvl: Yeah, I've been also working on some, some of the last bunch of tests. Those cover system contracts. So those, like, beacon Root and other system operations, trying to see if those work in isolation well, and with, User contracts, so we should have those. In their messages.

Mario Vega: Thank you. Alright, any comments, from… Yield apps on block level access list. If not, thanks so much, Stefan and Felipe, for the work that you guys have been putting on this, and yes, it's nice to hear that even though we are having failures, we are creating tests with it, so I think that's very helpful and very fruitful. So yeah, let's see if we can launch the number one in the following weeks. Cool. So, if nothing else from Block-level Access Lists, thanks for sharing the updates. We can move on to EPBS, and I see that Justin Jory shared a update on the comments. Would you like to, chime in?

Justin Traglia: Yeah, sure. Thanks. I can just give a recap of what I just said then. Yeah, we had a breakout call on Friday. It was very long, it went, like, 25 minutes over. We talked about dynamic penalties, which, could solve the free option problem, for… yeah. in EPBS and out of EPBS. The non-Staked Builder API from Brath, there's a Discord thread that we can talk about that in, if you want. And, trustless payments. We didn't make a decision about trustless payments, at the breakout call, but we're planning to make that decision. At ACDC, this week. So please review the arguments from, like, both sides, so that we're prepared to make a decision. The next breakout call is December 19th, and that's also the last EPBS breakout call. We'll start doing that here at ACD… ACDT.

Starting in 2026. And then I've been personally working on refactoring withdrawals code and the specs. Yeah. Do client teams have any updates?

Mario Vega: Just to surface one comment from Barnabas, last Friday on the call, we didn't hear any significant amount of argument why we should remove trustless payments.

Justin Traglia: Debatable, I don't know.

Mario Vega: Desperate.

Bharath Vedartham: Yeah, I think one thing outside trustless payments, in EPP, yes, is that, One thing, to… to make a decision on and to decide is whether we will have, unstaked builders in EPBS, like, so there's been debate on, Whether, clients will even, like, reach out to Builders who are not staked, or whether will we have builders Right? Basically, whether… today, none of the builders are staked, right? We have off-chain entities. The decision of whether, like, clients are gonna, like, only support, like, stake builders versus, like. okay, we're gonna support… we're also gonna, like, talk to stake builders, and also gonna talk to unstake builders. I think that's probably also a decision, we might want to make. I don't think that'll happen in ACDC on Thursday, but I think it's just… it's a conversation, because there are some implications, like.

we probably wouldn't have to maintain, like, the builder specs anymore. I think MevBoost would kind of, like, get out of the picture based on that decision. So, yeah, on my part, like. I have written a couple… a design for the builder API, like, I've iterated also a little bit from last Friday, from the EPBS breakout, because regardless of whether we support staked or unstaked, it's a useful data point to have on how the builder API will look like, so that we can make a decision, like, like, oh, it's too complex, it's not worth it. Something like that. So… so yeah, that's… that's another decision, we probably have to make for EPBS. I've heard a bunch of conflicting opinions, so… yeah, it's probably… as Justin mentioned, there is a thread in the Discord chat, so that's a conversation, like,

Like, I think we should start and, like, move on, right?

Mario Vega: Thank you. Alright, and one good comment from Katya, is… there's a question about whether we should be defining some PBS metrics across clients, to gather during DevNets. I think that's… that's important. Do you have any idea on that, or is it too early to decide? Alright, maybe it started. Cool. Any other comments on EPVS?

If not, we can move on. Please, join the ACDC to continue discussing this, and also the breakout call on December 19th to join the discussion. To make the decision about rotors pavements. Alright, so moving on, on the last topic of the agenda, we have the, The gas topic, or basically the stateless, sorry, the state, Benchmarking, and compute benchmarking. Do we have, any updates on this topic? Camila, I see that you are on the call. Anything to share here?

Kamil Chodoła: Yeah. Hi. So, we have two things which we are working on right now. Most importantly, focusing with all our efforts right now on repricings. So we have a tooling, how to tackle that. We are just making some improvements. On a Thursday, I noticed a few of the scenarios which are not behaving properly under the EST Execute, which Louis is taking a look at right now. So we'll have a better approach for that. Last week also, we confirmed some stateful scenarios performance, which improved on Nethermine sites, specifically, because Nethermine seems like it's a little bit slower than others because of the DP design. And right now, our efforts internally are in determined arms to make a better DB design, to not be a blocker for any potential future gas increases.

And yeah, so… and one more thing is we have this new process for filtered, what, 100 megacity blocks for a compute testing. I've seen updates from Spencer on that, and want to include that so we have a better… more frequent updates of testing scenarios out there. So, yes, we are progressing. I want to make some… make sure that maybe some further bump of 75 megas blocks is viable in short term, but doing some improvements to confirm that.

Mario Vega: Excellent. Yes, thanks. On the artifacts for… 100 million gas tests. We do have a new workflow, and it should be running at the moment. Basically, this is gonna generate New benchmark tests, state, fixtures, sorry, to… To be released. On a more frequent basis, and this is just gonna be a release of 100 million gas. So, this should be available using the artifacts download, come on, come online from GitHub. I think we can share more, more details on how to access this, this, this async. But yeah, basically the idea is that we are gonna be able to make releases… not releases, not for releases, but the tests, they're gonna be available much sooner than the release cycle that we've been having so far, up until now.

Cool. Thank you, Camille, for the update. And yeah, Spencer just shared, The details on this, on this update, on the, on the, on the artifacts. Excellent. Anything else on this topic that anyone wants to chime in?

Kamil Chodoła: Yes, just last thing is that for repricings, which are very tightly related to gas bumps for future, internally, nevermind, we are working on better traceability of the blocks from the past. So right now, we have only RPC calls, and RPC is quite slow for tracing the historical blocks, Or at least to check the… how the blocks look like, so not full traces, but for… but only opcode traces. And right now, we have a Netarmind plugin, which is capable of tracing… tracing quite a huge chunk of blocks very, very fast, just to get information which opcodes were used. Right now, it's under testing, Right now, executing a trace for 1 million blocks of Sepolia. And it will be much, much faster than MPC stuff, but it's still waiting for the result and some… fixing some issues.

But this might be interesting, so anyone interested in such data, let me know if you have anything you would like to learn more. Just accept the round number of upcodes per range of blocks.

Mario Vega: Excellent, thank you. Do you have a link for this, or.

Kamil Chodoła: Not yet linked, because this is, like, very, very early stage. I mean, we are right now testing it. Once PR will be published, I will send the link.

Mario Vega: Of course, thank you. Cool. Anything else anyone wants to share about the, benchmarking?

Marcin Sobczak: Yeah, we have, we have a spec for, for newer PC endpoint testing period block. it will be, to… to be blocked from provided transactions, and, like, SPAC is drafted, and, we have, proof of concept implementation in our mind, and I also saw that REF has some implementations, so, We are at this page, and in Nevermind, I need to fix a few minor issues, so it's generally written, but I need to fix it to work overly.

Mario Vega: Thank you. I shared the link for this, this proposal, please take a look. I think it's important that we decide on what do we want out of this, endpoint. It's also gonna help testing, because it, in theory, we should be able to even field tests using this endpoint, so it's gonna be very, very fruitful. So please chime in, if you have any ideas, especially from other EL clients, If you have, like, comments, or if you think this is gonna be… there's gonna be trouble implementing this, just please, right… right now is the correct time to… to come in and chime in into… into… into this new proposal. Alright, thank you, Marxing. Yeah, alright, I think we… with that, we finished the last topic. Do we have any other…

Any other topics that anyone wants to chime in? Before we close?

Spencer Taylor-Brown: Hey, I just wanted to, I guess. Bring up a small, kind of, testing organizational question. I guess mostly for EL client devs, and then also DevOps, so… I guess since last week, we have the new CFI EIPs. So the way I see it now is we kind of have like, these free tracks going on for Amsterdam, and so the free pricing, block access lists, and then the new CFI VIPs. Last week, We internally spoke in our testing meeting about how we want to do test releases, and… Basically, we want to start working on the new CFI DIPs, the specs, and get some tests out, so I guess I just wanted to ask the question to…

EL clients prefer that we… and DevOps prefer that we, kind of… test these new EIPs separately outside of block access lists? I think, for us, that's what we prefer, so… Just to throw the question out there. I think we should have, these separate block access list test releases, and then maybe separate test releases with the new CFI DIPs, and that would… that would encompass all of the new CFI DIPs, if that makes sense? Or if anyone has any better suggestions. Yeah, just throwing the question out there, just to… See if we can, get Glamsteram tested as efficiently as possible.

Mario Vega: Amazing. I think, yeah, Dragon?

Dragan Rakita: I don't have a preference here, but… It feels that clients are making good progress on the ball. So it seems okay to test all of them with the ball. But… Yeah, because we are… when we are testing new IPs, we'll be testing a ball in the same place. So maybe it will be a little bit better, but yeah, seeing it again, I don't have a big preference here. In general, if there is no ball inside the state test, or blockchain test, oh, no, not state, but blockchain test, we will not create a compare ball at all. If there is ball, we will compare it. So either way works.

Mario Vega: Got it, thank you. I think the main question is how far ahead are decline teams? I don't think much, because we just decided this last week. But yeah, the testing team, I think we can go either way. We can just make the releases on top of block-level access. In my opinion, maybe if we do this approach, it will expedite the testing, because if you are testing everything together, it's gonna end up faster in the DevNets, so maybe that's beneficial. So we could explore that, maybe, Alright, any comments from all the, all the other client teams on this? If not, we can take this to the team, and maybe we can make a decision and update you guys async.

On, on the, on what we have decided. Basically, just whether the EIPs and the block load access lists are separated or joined together. And, yeah, just one comment. Seems simpler to test with access list, but that's your preference, yeah. Yeah, I personally would, would, lean… towards putting the EIPs with the black glue accesses already, just to make sure that we are testing faster. For the future devoids. Makes sense. Okay, we will go with that approach. If there's, And updates in the meantime, before next ICD, we can keep you guys updated on the async channels. Or if we find any issues, or if we have any problems with this approach. Yeah, more comments supporting this. Okay, sounds good.

Alright, thanks for the input. Alright, anything else? That, anyone wants to share today, before we close up? All right. If not, I think that's the end of the call. Thanks, everyone, for joining, and happy BP01 fork tomorrow, and see you in ACD on Thursday. Bye. Thank you.

Stefan Starflinger: Bye, alright.

Dragan Rakita: Mine.

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