All Core Devs - Testing #55

Transcript

Mario Vega: Hi everyone, I will be leading the call today. We're just gonna give a couple more minutes to give everyone time to join, and then we can start.

Antoine James: Yes, sir? Just a… Yep.

Justin Traglia: Hey Antoine, you're unmuted, by the way.

Mario Vega: Hey, Akash, I think we have enough people, we can get started. Just let me know when to start.

Akash | ECH: Yeah, we are, like…

Mario Vega: Thank you so much. Good day, everyone. Welcome to ACDT number 55 to this September 29. We have a lot of items in the agenda today. I'm gonna share the link to the issue so we can follow along. This is the one… And… we can start with Fusaka. And the first item in the agenda is DevNet3. As far as I know, we have DevNet3 running, and we don't… no longer have DevNet 5 running, so… Do we have anyone from Epand Ops to give an update on DevNet3? I see there's no finalization, as I can see right now. Is… is this suspected? Is Piquet Indy or Barnabas in the call?

pk910: I think Barnabas is not here yet, but, yeah, we've just figured a new, unfinology test on DevNet3, so, that chain split, and… The unfinity is kind of expected for now.

Mario Vega: Thank you. Do you know… do you have more context on this? Do you know how much is this test gonna last? Or is there any action items for client teams to take care of on this, or…

pk910: As far as I know, the unfinity test was requested by some clients. It will probably last for one or two days, and then we'll, Deploy the proper clients again, and see if they can recover properly.

Mario Vega: Excellent, thank you. Let me see… Alright, Cool. Is there any updates from clients regarding dentistry? Any findings that want to be shared on this call? Either ELs or CLs? Who want to chime in on… on the… on this subnet? Alright, yeah, okay, since no updates, I think we can move along. Good. Yeah, and the next topic is the… there was the announcement, the blog post, I mean, regarding Fusaka, so we now have the schedule and activation times for Holeshki, Sepolia, and Holy, with Holeshki happening this Wednesday. I think… All of the release versions are now up in the blog post.

yes, Bari, yeah, we just finished that. Do you want to update something on the DevNets? Yeah.

Parithosh Jayanthi: Not sure what updates were already mentioned, but we have Holsky ShadowFork up as of, like, half an hour-ish. The network seems to be finalizing. We're discussing with the Aragon team why the node's not able to keep up, but it was able to do the ShadowFork, so it's likely more peer-related than anything else. And, Bezoo's billing blocks, but it's billing it without transaction inclusion, so they've also been informed, and… Would be great if they can have a look.

Barnabas Busa: And we have also submitted, some pop-up transactions, and exits.

Parithosh Jayanthi: Exactly, so we should have, all the queues full at the time of the transition, which was able to catch a few bugs in the last week. And the transition should happen in, like, the next half an hour, I think.

Mario Vega: Excellent, thank you so much. Should we jump into Manage Health Fork, now?

Barnabas Busa: We're gonna be doing other testing setup works before we do main initial work. I think we're gonna be waiting for the minute releases before we do maintenance of work. That's gonna be at least a month away.

Parithosh Jayanthi: Yeah, our plan is to use the latest releases from all the clients to do the shadow fork for the immediate next testnet, try and catch all the bugs that we can. And the other line of testing is that DevNet 3 is still up and running, and Banervice triggered non-finality today, so we let it non-finalizing for about 2 days before joining it back, so that we can make sure that the releases are also able to recover. And parallelly sync tests are also running.

Mario Vega: Excellent. Thank you. Cool. Yeah, it makes sense to delay, mainnet Shadow Forks until we have, like, the releases for mainnet. Alright, cool. Oh, going back to the activations, we have Holesky on… on Wednesday, and I wanted to touch upon the topic of client releases. Is there any updates on client releases so far? Please check the blog post to see if the client version that is pointed out in the blog post is up-to-date. If not, is there any update from any of the clients? Are we ready for, for Wednesday?

Pawan Dhananjay: I think for Lighthouse, it wasn't, listed earlier, we just had a release today. So I think the blog post can be updated with the… Specific thing? Yeah, okay, awesome.

Parithosh Jayanthi: Yeah, we already have it, it is waiting to be approved.

Pawan Dhananjay: Okay, thanks.

Mario Vega: Excellent, thanks so much. Alright Any other updates from clients, regarding, Holeshky support, on the releases? Cool. If not, I think we should be ready, and we can discuss the transition on next ACDC on Thursday after it happens on Wednesday. The BPO activation happens next week, so we'll have, ACDT, to discuss, first the… transition into Fusaka on Holeski, and then the BPO, if there's anything that we need to fix before… before it happens next Tuesday. Alright. Cool. Yeah. And next thing, we have a couple of topics on, execution client testing on the east side. There's a new release, version 5.2, which is basically just small updates, to the…

to the exception mapping, so there's not… nothing from the client size to do, as far as I know. And we have, 5.3 version of East, which is pending, and we will update the blob schedule. And with that update, we're gonna also verify the client design configuration via, if underscore config, and we're gonna use the execute config application in the, in East to verify the… the releases. If we find anything, we're gonna ping the clients, To see if there's any fix that needs to be done from your side. Alright, let me see what's next? Shadow Fork, we already discussed. Hmm… Anything else on Shelfworks that I might have missed, or anyone wants to chime in? But I guess there's not much to discuss, since Holesk is not… sorry, since Shellfwork has not yet acted at Fusaka, we can discuss that on the next call, I guess.

And the last topic regarding Fusaka is the Sherlock Fusaka audit contest. I think it's still ongoing. Is there anyone here that wants to give an update to this?

Justin Traglia: I can just say that it's going well, and there's, 2 more weeks left. And the competition.

Mario Vega: Thank you. Alright. Alright, that's everything for Fusaka. Anything that I missed, that we need to discuss today regarding Fusaka? Anyone, anything that anyone wants to bring up? Important findings, or anything related to client box? Frederick, do you like to expand on this?

Fredrik Svantes: Oh yeah, sorry, I think, yeah, we already have a Fusaka directory in the, PM repo, but, We should, make sure that… We, we add the relevant files, for the… that's what Harry listed out to do, basically, and we should do that as we have done for Pictra, for example, basically, create the plans for for the different, testnets and mainnets, so that we follow the process that's been set up, so that we don't miss any specific steps in testing and, yeah, other aspects. I think Tim used To do that, but, since he's away, so on. Should probably take up that torch.

Pooja Ranjan: I actually see a folder created in Ethereum slash PM, it is for Fusaka, maybe we would want to move all the related files in this folder.

Fredrik Svantes: Yeah, it's just a paradass readness checklist in there right now, and then we should…

Pooja Ranjan: Yeah, we can have all the PRs to move all related files in this folder, and then we will add it to the network upgrade folder.

Fredrik Svantes: Yep.

Mario Vega: Who wants to take on this, this task? Since Tim is out of the office.

Pooja Ranjan: So, I mean, I would recommend here that we add all the related files in Fusaka folder, and once that is done, we can move the Fusaka folder to Network Upgrade… Network Upgrade folder archive, which is right now. We can update it right over there. But first, let's move all so anyone with related information, make a PR, and I believe Nixo will be in a position to, merge all the PR. Yeah, Stokes as well.

Mario Vega: Excellent, and Alex pointed out that he can start the, the PR for this. Thank you. Alright, let's see, alright, anything else? Related to Fusaka, or should we move on to the next topic? Cool. Alright. So, next topic is, gas limit testing updates. And the first subtopic is, the mainnet 60 million gas activation in the Fusaka releases. Any comments on this regarding clients? I… I'm out of context here, regarding whether the clients added or not the 60 million gas limit, so if anyone can chime in to… To comment on this? Any of the clients, I mean?

Like I mentioned that GET is ready for 60 million, and it's in the release, I presume. Andrew, sorry, yes?

Andrew Ashikhmin: So yeah, I have a question. Do we want, it to be included into the, testnet Fusaka release, or in the mainnet Fusaka release?

Parithosh Jayanthi: So, testnets are already at 60 million, so it shouldn't really matter if it's included in the testnet release. I think the main intent is that it is included before the mainnet release.

Andrew Ashikhmin: Okay.

Mario Vega: Any other clients? I see Nethermine.

Kamil Chodoła: Yeah, I can chime in here. So, we have a PR with 60 for NetherMind. From a testing perspective, I know that GEF have API system to make sure that 60 is working well. That's also improved quite a lot. I get back after a longer break right now and still analyzing the data, and the outstanding thing from testing perspective is still Zen testing, which I'm discussing right now with Johan and the team, so hopefully this week we'll be able to test it and give some extra input on that. Yeah, from NetherMind perspective, we have APR, which we'll include on my net release.

Mario Vega: Excellent, thank you. Yeah, and we have a… we have a topic for discussion today on compute and state benchmarking, so we can, dig deeper in that section. Any other clients? I see Bessu in the call. Do you guys have 60 million gas enabled in the test and releases? per minute.

Ameziane Hamlat: Yeah, so it is not on the testnet release, but, yeah, it will be on mainnet, for sure. For the mainnet release, I mean.

Mario Vega: Perfect. Thanks. Any other clients? Let's see… is Reth here? Is anyone from Reth in the call?

Jen: Yeah, Riff is ready.

Mario Vega: Excellent. Is it in the… in the release already?

Jen: Yes. I can send it in the chat.

Mario Vega: Excellent, thank you. Alright, who am I missing? I don't think any other clients are here. Cool. Excellent. Okay. Thank you. Yeah, and there's, just another… bullet point on this is we have a proposal in the East repository. to update the, directory structure that we have for benchmarking. I think we can, discuss, but I… maybe… maybe it's out of topic for this call, but just for everyone's reference, we currently have benchmark tests in the East repository, and they now are gonna be divided in two sections, and we can discuss those sections in a bit, but basically the compute is one section, which is basically a state, A small state in the test, but, a lot of competition, and then state which includes, a bigger state for, bigger… I'm sorry, for more intensive, state testing.

And please, follow the link, and you can see how we're gonna restructure this. It's very simple. But yeah. With that said, I think we can jump into compute-intensive benchmarking. We're gonna… There's just one subtopic, so please, if anyone else wants to raise another topic, another discussion topic for this, please raise your hand. But yeah, the only topic for discussion is that we're gonna have an update on the, on East, to update the format, the testing format for the benchmark tests. I don't think there's anything to be done from client side on this, it's just basically a better way of writing tests. As far as I know. So yeah, there's no action item for clients. Basically, it's gonna produce the same blockchain test and the same state tests that we have already produced, so no changes in the conception of these tests, it's just a matter of, like.

just, making it easier to write the benchmarking tests. Let's see… Luis, yeah, if you want to chime in just, on this PR, just please feel free to. If not, we can continue. Yeah, and the next, topic is the state benchmarking. I think Johim, is prepared for, to give an update on this. So yeah, Johim, just feel free to…

Jochem Brouwer: Yeah, yeah, thank you, thank you. Yeah, so I think I am bringing this topic up every week, so that's very nice. So, again, we want to create state-intense benchmarks, and this is, like, these are kinds of new tests that Which we don't really have the tooling for yet to run these tests. And what we want to do is we want to run tests against, clients with, like, a large state, for instance, mainnet state. And then we want to see and to figure out what are, like, the worst-case situations here which can happen. I'm working with Camille from Nevermind on this tooling to run these tests, and of course, if we want to run tests, we also need to have the situations which we run on.

Obviously, Xen is a candidate for this, because the Xen contact has a very large storage, and what I would like clients to think a bit about is what is actually the worst-case situation in your client. So, we are thinking about state, and we could say, okay, maybe deleting state is the worst-case situation, or updating state is the worst case situation, or writing new storage slots is the worst-case situation. That, I think, completely has to do with the implementation and the optimizations which a client does, which I have no ID for at this moment. Or maybe there are even more exotic situations where, well, a client might have optimized something very well, but now has a very specific area where the behavior is now very, well, bad. And of course, we need tests for this, so if you have, like, a very specific situation.

where you would like your client to get a benchmark for, then please let me know. I can write these tests, I will I would love to write, write these tests. And, Yeah, we would really want that we have these tests, because we want to update the gas limit, we want to increase this on mainnet, that's fine, but we don't really have eyes yet on, like, these worst-case situations for the state. And we can… so we are writing this tooling now to run these tests, and I think that will be done very soon. And then we can use these to actually perform these tests in an isolated environment, so we can know beforehand what, like, the areas of optimizations for clients are.

So if someone has, like, an idea for extra tests or other situations, then please let me know. But, yeah, let me know that the state benchmarks are coming very soon. Thank you.

Mario Vega: Awesome, thanks. Is there anything from the east side? How are we approaching this, the testing of this? I'm curious about how our… Yes. I mean… To paraphrase my question, I think, are we including the big state on East, or how is the big state, Gonna be included in the tests.

Jochem Brouwer: Yes, this is a very good question. So, the test itself is, so specifically this XEN test, but likely also every, every other test for the state benchmarks, they will be written in EAST. And what you will do is you will use the address step. to target a specific network, so, for instance, like mainnet, then you would use the XEN contract for your Xen tests. And what you would then do, and this is… this is why we need this extra tooling, so you do not… you can obviously not put the entire pre-state into the pre-state files of East. So what you will then do is you will spin up a node. And the current tooling, what we are using, is we have basically a CL mock, which drives the chain to run these tests on, and this generates the payloads for the client to run. And then to actually run this test, we replay these payloads on top of other clients, and then we see how they perform.

And these other clients, they all run from the same snapshot. So, you basically, you start the chain, you use this snapshot, and then on top of this snapshot, you run the payloads generated by these East tests.

Mario Vega: Got it, got it. The tooling that you mentioned that you're missing, is that on the east side, or on the client side?

Jochem Brouwer: This is actually, well, basically a third-party tool currently. So, this is tooling, that's currently, it is, well, okay, this tooling is currently my own custom tooling, but Metamine's guest benchmark repository is, I think, the repository which will include this thing. But personally, I would say that this is also something which we would likely want in East as well.

Parithosh Jayanthi: I would actually see if we can have it as a fully independent tool with a way to hook it into EAST as well as another man tool, because I can also imagine the mock CL ability is something we can use elsewhere, right?

Jochem Brouwer: Yes, that's true. Okay, maybe as a standalone tool, that would actually be maybe a bit more logical, yeah. Interesting, yeah.

Kamil Chodoła: Yeah, so… I was seeing that in the beginning, it's like, IST is having the definitions of the tests, and it can contain definitions for tests which are specific for the chains, like, we often is right, for example, on mainnet. We can have specific tests for blotnet, we can have specific tests for any testnets, if you would like to. And then we have the site tool link, which for now probably will be GAS Benchmarks, which will be responsible for generating the payloads. Here we are using some custom version of Netarmite, which will be generating the payloads on top of that state. And then, also, like, what Gazelle actually have right now is the execution of those tests, using some VMs which are having,

backups of all of the clients ready just to be mounted. Test will be executed, and the state will be, afterwards, reverted to the initial state. So, like, the separate tool, but it will always have all of the definitions of those tests. Long term, we can see if we can integrate that to EAST, but probably, as Pari mentions, it's like, it's better to have the execution part being outside for that, because this is quite heavy, and not really… like, not to be very useful for EAST to have it, rather East to be a repository of tests for that.

Mario Vega: Makes sense. Thanks so much. Alright, any questions on this topic for Joachim? From clients, I mean? Primarily.

Andrew Ashikhmin: Yeah, so I have a question, like, when you say snapshots, what do you mean by snapshots?

Jochem Brouwer: So, a snapshot will be any… I'm specifically meaning, if PandaOps snapshots, but this is basically, like, I think PandaOps at every… yeah, thank you, Barry. Like, every 10,000 blocks on mainnet and also on testnets, I think it's every 10,000 blocks, or maybe 100,000 blocks, they release this snapshot, so you can directly download this snapshot and, use that as your Well, basically your state's database to run the test form.

Andrew Ashikhmin: Okay, I see, thank you.

Mario Vega: Excellent. Messien?

Ameziane Hamlat: Yeah, I have a quick question, related to, these tests. How close are they from the transactions that we see on mainnet? Because, for example, when I look to your… to the comment, I see 7,700 as a store, and 8 has slowed. And, on base's side, if I remember correctly, when, we were looking into it, like, the most, like, the biggest bottleneck was actually S-load. even, like, on the Xen contract, transactions, and, which, which, which could be, you know, weird, like, when, at, at, like, first place, when we… when we know that, like, there are more SS stored than S loads, but… The thing is that we found that most of the S-load were actually on

were actually, zero reads, so basically slots that, don't exist, in the state. So, I was wondering how… Is this something that you already have in the tests, or…

Jochem Brouwer: Yes, okay, very good question. So, I think what you meant is that you, specifically were looking at replaying mainnet transactions, so replaying the mainnet situation. Well, this is doing, basically that, but even worse. And what I mean with worse is that on mainnet, what you see for the Xen situation is that tokens are being minted, and, this, this has some extra computational overhead in the contract itself. So it does, like, some extra logic. What I'm trying to do is I want to write, using the existing Xen contract, as much storage to the present contract as possible. And one of the ways to do this, and I'm not sure if this is actually the worst-case situation, but this is likely

Well, bad enough, is to call the approve function. So what you do there is you can approve, like, another address to spend your tokens, even if you don't have any tokens yourself. So, for this situation, like, on the mainnet transactions, you will see, like, less S-stores and maybe more S loads. The tests which you saw in the comment is specifically looking only at S-stores, so that's why you see, like, only 8S loads. I will, of course, also implement a test, which focuses on the S loads, because this could, of course, also be a bottleneck, so these specific tests are only looking at the S-store, but this tries to squeeze out as much S-stores as possible on XAM.

And I will do the same for SLoad. So yeah, this is basically a worst… well, a more worse situation than the things we have seen on mainnets yet, and of course, this is with the side note that I am running these tests on an isolated node. So they are not running, like, any networking or whatever, so that's more optimal. But in terms of execution itself, this should, well, in practice, it can happen, but likely no one wants to spend their money on this. So… This might be, like, a very good approximation of the worst-case situation for S-store on mainnet.

Ameziane Hamlat: Thanks.

Jochem Brouwer: And of course, if you have, like, any other ideas for these kind of benchmarks, like, please let me know, or if you see something weird. please reach out, because I might either have done something, like, super, super dope, or there's, like, a very good explanation for it, so please reach out if you have any cool ideas on how to make these situations even worse.

Mario Vega: Thank you. There's a great question from Maria on the chat, whether this is only seen on the same contract, or if there's any smaller contracts. I assume it may not, maybe, that exhibit the same behavior. Do you know if that's the case? For other contracts?

Jochem Brouwer: I think a client team should, chime in on this, but I think all clients use, like, some kind of… well, for the Snap protocol, you have, like, a 01 lookup time for SLoad. So, I think it does not matter if you have, like, a very big contract or a very small contract, but of course, this also depends on the implementation and the optimizations.

Mario Vega: Excellent.

Marius van der Wijden: Yes.

Mario Vega: Secure.

Marius van der Wijden: So, exactly what, what Joachim said. The only, the only thing, That can be different is if you are… if you are loading… S-loading something that is, that is cached somewhere, or if you're S-loading something that is non-existent, or if you're… as loading, like, existing… existing data. Those are the three different, different things, but it's not… not really dependent on the size of the contract where you're… where you're exploiting from.

Mario Vega: And there's, another question… So for Bessu, are there any changes in optimization that may make this different from other clients? Do you have someone from Besu that could, chime in?

Ameziane Hamlat: I mean, it depends on the question. For example, we had a few discussions during the interop with, with some… folks from Wrath, So, for example, Wrath, like, the… if I remember correctly, the bottleneck was on… the hash calculation, like, the root hash calculation. So, on our side, we, we preload the storage slots on the, like, during, during transaction execution. So, like, each time we touch, one slot, key, we preload, all, like, the, the branch, the branch nodes to… So then we can, you know, speed up the root hash calculation. Yeah, so that's, like, that's the main, I think, the main… the main optimization on the… on the root hash side. But I don't know if the question is related to something else. But, for example, for the S… like, for, like, the S-load performance on…

on zero leads, so this is something we're already aware of. So there is, like, there is one small limitation on the LuxDB side, so there is a bug in OroxyDB that, so basically, which is basically, triggering, an issue like, an exception when there is, when there is a zero read, instead of just returning whatever, you know. So we… there is a PR that is pending, but it is not matched yet. Yeah. Yeah, so yeah, apart from that, Yeah, that's all, actually.

Mario Vega: Thank you.

Marius van der Wijden: Yeah, so… Just to expand on this, we also have a, we also have a problem with non-existent weeds. Well, it's not a problem, but it's, like, whenever we do When we read something that is non-existent, we need to go through all of the in-memory diff layers, and then go to the disk layer, which is a load of work for reading something that is non-existent. So actually, like, the existent read is… Quite a bit faster than a non-existent REIT for us.

Mario Vega: Cool, thank you. Yeah, and just to echo Johann's, if there's any particular interesting ideas that you want for him to write a test for, I think it would be very good if you guys can reach out. I think this particular scenario that you're mentioning, Marius, I think it would be very nice for us to also have a a compute test. Maybe there's something that we can do on the compute side. For that. For MTS loads, I mean. Cool. Alright. Anything else? Any other questions for Johan, or on this topic that we want to… Race…

Jochem Brouwer: Yeah, I just want to note, as final point, that, as you mentioned, it would be very nice if people could reach out, like, this kind of situation, I would like to see tested. But my goal is also for myself to go into these clients, to all of the clients, to see what is being optimized and what is not being optimized. And to see there, okay, what's, like, the worst case situation that, well, how can we abuse this optimization, or how can we not abuse it? But it would be really helpful if I could have some help on that, because it's, of course, much harder to figure out the code on yourself, instead of talking to someone who wrote this code, yeah.

Mario Vega: There's also a nice point, by Ben. If… We could change as a store to not check the current value for pricing. So just to paraphrase that, we need… we would need an EIP for that, right? Just to basically not… Having the current value to be a precondition to calculate the gas pricing for that. Yep.

Ben Adams: Yeah, so… So, obviously the reason it does check the current price is so it can correctly Add additional… Costs for state growth. But it's also the most expensive part of S-Store, is that. Searching for the current value. And that's… that's where, usually, checking for a value that doesn't exist comes from.

Mario Vega: Thank you, thank you. Cool. One last comment from, CPRS, All of the case… he posted a link. I assume this is a list? Yes, this is a list, of test cases that will eventually make it into East. Just for everyone to go over this list, because this is something that we are already working on, so if your test case is not in this list. please chime in on make… or make a comment, I guess, that would be the best, approach. Make a comment into this list so we can add a test, a scenario that will eventually make it into East. Yep. Alright. Thanks. If nothing else on this topic, we can jump into Glamster then. So, the first agenda item is that we have a new Consistent Specs release that happened last Thursday, version 1.6 Vita 0. So, Justin, do you have any… anything else to add to this?

Justin Traglia: Not really, I mean… Yeah, there's a new release, EPBS. Devnet Zero will be based off of this as well.

Mario Vega: Alright, thanks. Just for clients to be aware, just to consume the tests, I assume. Yep. So, yeah, and jumping into specifics, so we have, block-level access list and EPPS, for Glamstrom, so we can jump into, block-level access list first, and then into EPPS, if there's any topics. So, I see the first, comment, or first bullet point, sorry, is from Rahul. Let me see if he's in this call… Let me see…

raxhvl: I'm here.

Mario Vega: Oh, yeah, sorry, there you go. Yeah, can you chime in on the blog access list? Any, any updates that you want to share?

raxhvl: Sure. In our last release for block-level access list, that was version 1, We focused on simple happy, path scenarios for block access lists. And since then, we've been working on some complex test cases. And throughout our testing, what we found is the intersection of block access lists and some existing EIPs, such as 7702, is quite nuanced. For instance, when you create a 7702 delegation, the target account need not be read from the state for the delegation to be created. This is because the target account can't be read from the address directly. So we clarified this in the IP and added a negative test case to ensure That clients do not perform a state read for the target account when creating a delegation.

We also needed to, address some, system operations, like self-destruct and precompiles, which required some further, clarification. Those also have been updated in the IP now. And throughout this month, we fixed several bugs within the execution specs, and the IP has been refined to some extent to cover all our learnings and edge cases. That we've, discovered in the past month. We now have close to 30 test cases. That's currently under review. And, we should, should expect a release soon, YAM. Also, we'd like to proactively run test cases for clients. If you're a client and have not shared a dev branch with us. please do so. This will ensure that, we release a polished version of test.

And finally, if you're client dev that's new. to testing, or have any questions, feel free to reach out. Be happy to help you get started.

Mario Vega: Excellent. Thank you so much. Yeah, just to echo that, please reach out to Raul or Felipe, So they can, either point you to the latest block-level access list release in East, or they can help you out to run the tests for you if you provide the branch to do so. Cool. Any questions on block-level access lists, and specifics from clients, especially?

Toni Wahrstätter: I'm not from a client, but let me ju- let me just add one thing. We had the block of Access List breakout call on Wednesday, and we discussed, one important topic, that might affect more people than just those that were at the call. So it's about, do we want to do a block-level access list hash versus a block-level access list root? I won't rehash the whole discussion here, so please check out the Discord. I have summarized, The discussion, if you scroll up a bit, or you can also rewatch the breakout call. But this is definitely something… it's a small change, it's still open, so right now it's a block of access list hash, but it might make sense to move towards a block of access list route. The change would be rather small, but still, if we really want to go for that, we should decide, yeah, as early as possible.

So please, if you have an opinion on that. yeah, reach out, join the call, or, voice your opinion on Discord. And there's also a Eve Research post by Jason about, Block Live Access List X, pre-conf. That also, highlights why a route might be, beneficial for some use cases.

Mario Vega: Excellent. Thank you so much, Tani. Just to surface one comment from the chat, Karim mentions that there's a message in Discord that there's a missing test, for BESU that is related to block load exit list that we should check. So, thank you for that. Make sure that we can check that. Cool. And the other point is that, we have this link provided by Eve Bandelp's. It, It lays out the, the block level access list.net specification. Just please come here and see if the information is okay to you. I don't think we have a date, I cannot see a date here, so… It might be not specified. So yeah, there's no date, it seems, it's only slated for late, yeah.

Parithosh Jayanthi: There's no date yet, we're still waiting for Kurtosis conflicts to look good, for us to get a better idea of local testing that we can do, and then once there's at least 3 clients, then we're ready to spin up a DevNet.

Mario Vega: Excellent, excellent, thanks. Yeah. Alright. Moving on, the last topic today is EPVS. We also have a link from EidpandaOps here. Let me share it in the chat. Yeah, same… similar things, we have a Devness slated for the end of October, and I think we are missing the client branches, say, in this case, too. yep. Cool. So yeah, on the deeper topic of EPBS, is there anything… Any client wants to share on this, or do we have, like, more context from someone that can share? That can be shared here. Sorry, about EPVS.

Justin Traglia: I can probably just talk more. I mean, I know clients are working on implementing everything for the first DevNet. We'll know more in two weeks whether or not DevNet Zero can be launched at the end of October. Clients should provide an EPBS DevNet-0 branch for ETH PandaOps, to test with. There was some testing… Things that we need to figure out, and Katya asked if there are any metrics needed for EPBS? I don't know. That's pretty much it. I mean, we're just working on implementing everything.

Mario Vega: Alright, thank you, makes sense. Yeah, if there's anyone else that knows a little bit more about… I mean, probably there's no one right now, but, just try to keep an eye on metrics, I think that's a very interesting… Topic that we need to, resurface at some point. Thank you, Katya, for the question. Cool. Any opinions or anything that wants to be shared from clients regarding EPVS? If not, that's okay. Okay, cool. Yeah, that was the last, topic in the agenda for today. Is there anything that we missed that has to be discussed today? Please raise your hand now. Before we end the call.

If not, I think that's it for today. Thanks, everyone, for joining. Yeah, let's, Let's see, hope that the, The activation in Holesky goes smoothly this Wednesday, and we can discuss it on the ACDC on Thursday. Thank you, everyone.

Jochem Brouwer: Thank you.

Alex Stokes: Thank you.

Toni Wahrstätter: That's true.

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