All Core Devs - Testing #95

Transcript

Danceratopz: Good morning, everyone. Can you hear me okay?

Spencer Taylor-Brown: Nearly perfect. How are you doing?

Danceratopz: How's… how's the quality? Is the microphone all right?

Spencer Taylor-Brown: Yeah, sounds good, man.

Danceratopz: Okay, perfect. Good morning, good morning. Nice picture, Ivan. I think I recognize that view.

Saulius Grigaitis: Hello.

Danceratopz: Good morning, saulius. Good morning, Pooja.

Pooja Ranjan: Morning, Dan. So, the problem is you're not able to open an agenda?

Danceratopz: You mean the breakout?

Pooja Ranjan: Yeah.

Danceratopz: I just tried to… I just realized that's something that I should be able to do now, and I just tried to log in with my account, and I couldn't log in, so I think I'm actually even here as a guest. So… But, I know that Justin's joining, so maybe, oh, hey, Justin, just talking about you.

Justin Traglia: Good morning.

Danceratopz: Couldn't help. Good morning. Justin, I don't think I can create breakout rooms, because I'm not logged in.

Justin Traglia: They're automatic.

Danceratopz: What's that?

Justin Traglia: Automatically created.

Pooja Ranjan: Yes.

Danceratopz: It's just the.

Justin Traglia: 1CL1.

Danceratopz: Okay.

Justin Traglia: EL will continue to… The EL breakout will happen in this call.

Danceratopz: Amazing.

Pooja Ranjan: Yeah.

Danceratopz: How does it…

Pooja Ranjan: There would be another Zoom call for CL breakout, and the EL will continue in the same meeting where we are right now.

Danceratopz: Okay, got it. And how does this automatic creation work? Does it… is it… Is the AI listening to us, and then creates it?

Justin Traglia: No, it's just automated in the Ethereum PM repo.

Danceratopz: Okay.

Justin Traglia: Yeah, I mean, the Zoom, the Zoom room is just automatically created.

Danceratopz: Okay, got it. So everyone's just ready to jump in, like, it's already there waiting, basically.

Justin Traglia: Yep, exactly.

Danceratopz: Got it, thanks. Good morning, everyone. Just give it a few more minutes. For people to rock up.

Pooja Ranjan: I'm trying to find out the Zoom link for CL meeting in the agenda. I don't see it there. Am I missing something?

Danceratopz: Let me check… I mean, normally there's…

Justin Traglia: I see you.

Danceratopz: click on… You see it?

Justin Traglia: Hmm? It's in the, sorry, I'll share a link.

Pooja Ranjan: Sure, I mean, it's fine, yep, good. Thank you.

Danceratopz: Yeah, got it. It's in the, in the comment from the GitHub Actions Bot…

Justin Traglia: Was it not shared on the Discord comment?

Pooja Ranjan: Yeah, yeah. How could I miss this? Yes, sorry. Thank you so much. Yeah.

Justin Traglia: Yep, no worries, and I'll be sure to share the link, like, when it's time to join.

Pooja Ranjan: Yeah, because in the ACD bot, it only shared the main Zoom link, not the breakout room.

Danceratopz: Awesome. Perfect. Alright, I think we can get started. So, good morning, everyone, and welcome to ACDT number 95. Today is the 7th of September in 2026. And, happy Labor Day to all those that celebrate, A few people may be out, because it's a public holiday in the US today. I'll just drop the… Agenda in the chat for everyone to have a look at. I think at the beginning, we've got quite a heavy, DevNet round, and then following that, pretty much, I think, will go straight to the breakouts. So is Stefan in the call? I see he is, good morning.

Stefan Starflinger: Morning.

Danceratopz: Would you like to… talk about the DevNets in order, starting off with DevNet 8.

Stefan Starflinger: Yeah, sure. So, with DevNet 8, we had, Jochem. Abusing it quite a bit over the weekend. So, he's been deploying, contracts, 64 kilobytes, with JUMP desk spam. And he managed to knock out most of the Besu nodes, and a lot of the other nodes are struggling to keep up. We do have a lot of attestation still, so the chain does finalize. We didn't have any finality issues, but we do see that the proposals, especially also the payloads, are going down significantly. So it would be good if clients could have a look at optimizing these edge cases. And, maybe Jochem could say a little bit about, what exactly this test, does. If he's here.

Jochem Brouwer: Yes, yes, yes. So what this test does is, the first thing what was done is deploying a lot of, 64 kilobyte contracts, so we have raised the maximum contract size in Lambda from 24KB to 64KB, and that also means that we can only deploy these contracts in Lambda, and this is a hassle, because we've also increased the state gas cost, so this costs a lot of gas to deploy, so this actually took a week to deploy. And after this week, we now have enough accounts to theoretically target these for the 200 million guest limit. These are, in theory, well, 66,667 accounts, which, of course, in practice will not happen, because the block Box being built will not include all transactions which target these accounts.

These accounts are those unique accounts, so every account has a unique code hash, and, The content of this contract is, it's full with gym tests. And the start of this contact is just a push JUMP to the final opcode of this contact, which means you have to do 64 kilobytes of JUMP test analysis. The thing is, and this is interesting, because this is also a scenario on Benchmarker. And, what we have seen with… well, I've not analyzed this directly, but with Besu, we have seen that the nodes went offline, well, after a while. So this is being tested on Benchmarker. We did not see any problems on there, but if this is, like, a continuous attack.

the notes, some notes go offline. I've also not checked the other notes. All clients should take a look, except, Gav and Nethermind, which are, taking these boxes, well, just, just as normal. So all other clients should take a look at, well, what has happened here. And figure out, how this can be solved. So, yeah. Excellent.

Stefan Starflinger: Yeah, also to add some numbers to that, so Besu was missing, over the weekend, around 65% of the proposals, and, second, worst was Nimbus ETH1, and compared to that, Nethermind 5% and gets just 0.1% of proposals were missed. I think someone has their hand up.

Danceratopz: Yep. Please speak up.

Ameziane Hamlat: Yes. Yeah, so from Besu side, I started to look into the issue, I have actually one question around, around the tests. Have you, Johan, changed anything in terms of setup related, for example, to, debug tray scores? because… as far, like, like, what I'm seeing currently, it looks like more an issue on the memory side of things related to the BeChrase cores, other than that specific use case. So I wonder if there is, like, a change in the setup that makes more, Debag trace calls, or, you know, something basically different from what we had before.

Jochem Brouwer: Yeah, good question. I cannot answer this for sure, because the ad tech code which is being used, so, to target all these accounts, that might be different than the one, what we are using on Benchmarker. This is because this uses the spammer instance and not the EOS interface for this. But, on the other hand, this should not really change, like, a lot, because there's not something different in terms of memory usage or whatever, so this should only be, like, maybe some push-up codes in, like, a different place of the code. My suspicion will be that, so on Benchmark, we did not see this problem. But we are seeing this if we start spamming this network for a very long time, so this might be, like, a memory problem. And also, maybe a thing to look into is if Besu is caching the JUMP test analysis, that might also be, like, a factor, because we have, like.

So, just an idea, like… If we query for 300 million gest limit, that's what we are doing, we are for 200 million cash limit targeting, but for 300 million, that would target 4.2GB of accounts, that also means you have to do 4.2 gigabytes of JUM test analysis. If you cache this in your memory, that also means that you are just putting this cache Into, into memory. Maybe in an optimized way, I don't know, but that's something to look into. Yeah, I also recall that Besu had some trouble with the traces in the past, so that might also be something to look into.

Ameziane Hamlat: Yeah, so I, I was, I was actually, investigating similar, Like, similar kind of, options. So what I can see is a spike in memory usage, it's like a one big spike. So, I am still investigating, but this looks like, you know. More related to, maybe. the BeacRace call that consumes a lot of memory at once, instead of having something that would be, you know, that take slightly more time to fill in the memory if it was related to cache. Yeah, so, like, on the Pandora, like, on the Pandora side, there is nothing that changed related to DeBacrace, right? It's basically the same configuration as before, just wondering.

Stefan Starflinger: Yeah, there hasn't been any change, but I remember that Besu has pushed some improvements to their debug and trace endpoints, and the performance has been much worse in the past. And I think so far, I haven't come across any trace and debug issues. Of course, if there is some other issue, this will cause some contention. But so far it's been pretty okay.

Ameziane Hamlat: Yes, so that's why, actually, I was asking, Stefan for the, for the, for the, like, the call, the RPC call, because, like, the one that you shared is actually, taking the code path that we haven't optimized, and so there are different code paths in, In the backtrace, and that one is not optimized yet, so that, somehow, like, the… there is a PR to fix that, but, The memory usage was somehow expected.

Stefan Starflinger: Okay, yeah, I've, now disabled, some of the, debug and trace, areas for Besu nodes, and I've left it enabled on some others, so we can compare, and the spam scenario is running again. So hopefully it will be easier to understand and find the root cause.

Ameziane Hamlat: Sure, thanks a lot.

Stefan Starflinger: I think also, for the next point, I think Toni was also testing a little bit with invalid bars you wrote, before. Do you want to say something? There as well.

Toni Wahrstätter: Yeah, I was, publishing payloads and valves that didn't, so the bow was not for the payload, but both were, like, worst case. So the ball was maximum size, causing as many reads as possible at the client, and the payload was… doing as many KCG openings as possible. So… I… I won a bit, and then I published a payload a few… Slots later, and we are still investigating what impact this caused, but it seems like it surfaced an error with Nimbus, Which is, their… voting, the PTC's voting too early in the slot. I'm not sure how far we are in debugging this issue.

Stefan Starflinger: Anyone from Nimbus there? But otherwise, I think these were the main points on DevNet 8. Does anyone else have anything that they would like to talk about? Or definite Aid.

Danceratopz: Spencer's just asking in the chat whether we have, somewhere where we can document all these attacks. PK's answering that there are spammer configs in the repo. That's pretty good. Joachim's gonna add… There's a tag there as well. Joachim, you said… At the beginning, there's a benchmark or test case. Which basically does the same attack. Could this be helpful for Besu to debug?

Jochem Brouwer: Yes, I have shared a… Thread in a channel on Steel, Discord. I will opinion on Besu again for this, and also all the other clients which are interested.

Danceratopz: Perfect. And, PK, I'm just wondering… if… getting these attacks expressed as, EEST tests. Would be helpful to be able to run them through. Benchmarker in general, or maybe that's not entirely possible. If anyone has any con…

pk910: That's more a question for Rafael later, benchmarker things, but yeah, I can forward this to him.

Danceratopz: I said, yeah, perfect, thanks, Kate. I suggest we bring this up on the benchmarking call tomorrow. Take it from there. All right, perfect. So, Stefan asked if there's anything else, for DevNet 8 before we move on? Please speak up now. Anything from the chat that got missed that needs to be clarified? Okay, then, I think we can move on to… DevNet 9, which was planned to be a non-finality DevNet, and was, but in an unplanned way. Do you want to give a summary on that one as well? Stefan?

Stefan Starflinger: Yeah, yeah, sure. So, the network started off, with a thousand nodes, so it was a very, very big network. And there, we wanted to test non-finality, so we would let the nodes kind of miss proposals for a longer period of time. But we had, quite the challenge to even get finality with, DevNet 9. From the beginning, because, there was some miscommunication, on a kind of readiness. And a lot of the nodes, I think 30% of the network went offline pretty quickly. During the Gloas fork, that was mainly Prysm. We deployed the trunk branches, and they didn't have all of the latest changes there. So, they couldn't go through the fork transition, which took a lot of the network offline straight away. And so, Layer 2s also didn't, have time to test, the fork transition.

Very well, because it wasn't, finalizing. Also, the watchtower was running, and because we were using trunk branches, nodes were updating quite regularly and quite often. And the second issue was that when restarting Lighthouse. There, were some, caching inefficiency, so the hash of the nodes, pretty much exploded. And they went, OOM quite a lot, which was also, attributable to the large validator size that we had, so I think we had 4 million Validator keys on the network. Which basically stretched the resources, that all the clients had, even though we increased the node size to have 32 gigabits of RAM. gigabyte of RAM, but still a lot of the nodes, went OAM from Lighthouse after restarting.

And there were some other minor issues. I think the builder nodes also struggled a bit, because they have to be subscribed to all of the sub-networks for their proposals and their bids. Yeah, but in total, I think we managed to find a lot of different issues on DevNet9, but we decided not to keep it running for too long, because some clients were not ready yet. With the trunk branches, and it's quite expensive to run so many nodes in a network, and it would be more beneficial if we, spin it up again. So we're thinking about starting a DevNet 11. So we did a DevNet 10 for some… Decoupled consensus testing. Pk did that, and now we'll move on to, Definite 11 for the next one, and we can kind of discuss what we want to have from it, also.

That's kind of the rough summary.

Danceratopz: Thanks a lot, Stefan. Did… do we need to discuss anything? that happened on DevNet9 in more detail now, or are those discussions already happening async? being solved.

Stefan Starflinger: I think most of the discussions are happening async already for DevNet 9. Regarding PRISM issue, I'm not sure, does Prysm have an update? Maybe no one here from Prysm? I think we can… does anyone else have something for DevNet9?

Justin Traglia: James, just to be clear, does that PRU link fix the issue?

Stefan Starflinger: Yeah, it looks like the one that needs to be merged. To me.

Spencer Taylor-Brown: Dan, if you're talking, I don't think we can hear you.

Stefan Starflinger: Yeah, I just wanted to say. But otherwise, I can just, move on to DevNet 11. I can't hear Dan either. So… So, for DevNet 11, the idea is for us to coordinate with Layer 2s, so they can do a very nice fork transition test. For, what they need. And for all of the clients to be on their trunk branches, We can kind of discuss how we want to handle the watchtower, as well. So that the updates, happen in a more reasonable interval, so the network is not necessarily taken down through updates. And we also want to see a very smooth fork transition from the clients overall. I think, we are not gonna take biggest, Validator state for Definit 11.

But… I won't be here for, some time, so I will leave maybe that to PK, to decide. exactly how he wants to configure DevNet 11. And Rafael. Maybe, PK, if you want to give a short overview. as well.

pk910: Yep, I'm going to set it up, but the exact size and validator shares are not decided yet. I think the… Biggest gate is basically we are waiting for all clients to have their trunk paint, or their unstable branches ready. So, yeah. Waiting for Prysm, basically. And we've also planned to make that a happy path, network, so no stress testing during the fork transition or anything, so they are tools and everyone, Can test the heavy path there.

Stefan Starflinger: Yeah, and to Toni's point, I think we should give, some time for people to get ready before we do the Gloas transition, so probably we'll leave at least, I think, 24 hours, maybe a little bit more, between Genesis and Gloas fork.

Justin Traglia: Is that enough time for L2s? Or anyone that wants to participate.

Stefan Starflinger: We will also coordinate with them to make sure that we give them enough time.

Justin Traglia: Okay, great.

Danceratopz: Awesome. Alright, I hope you can hear me now. Thanks a lot, Stefan. I'm guessing that, once the Prysm, issue is merged, then we can potentially do this Or launch DevNet 11 towards the end of the week. Something like that.

Stefan Starflinger: Yeah, hopefully sooner.

Danceratopz: Yeah.

pk910: Midweek towards the end of the week should be fine, and then probably one or two days till the DOS activation.

Danceratopz: Perfect. Thanks, guys. Alright, so, that's it, I think, for our DevNet Roundup, and we can proceed to the breakouts. Unless there's something else that someone wanted to bring up. Spontaneously that should be discussed. Across the layers. Alright.

Justin Traglia: Alright, I've just shared the link to the CL breakout. I'm gonna leave this and join my room.

Danceratopz: Thanks, Justin. Alright. So everyone in ELs can stay in the school.

Nikos: Right?

Danceratopz: Just give everyone a moment to move over. Okay, perfect. Alright, so, I think we should start off with the… potentially the biggest topic, that Jochem wanted to discuss in the EL breakout, which was whether we ship EIP8253 with Glamsterdam. Joachim, would you like to… Take that one.

Jochem Brouwer: Yes, okay, so I've prepared this text with… people can read. Okay, so this, might first sound like, okay, why are you proposing, like, this EIP, like, now, in the final part of the, of this, this fork? The thing is that the block access list is not compatible currently with the current specification, what we have. And then I'm referring to the yellow paper, and then we have Formula 99 in the yellow paper. Which, says that if you create an account, so if you create a contract account, then you start with an empty tree. And without Block Access Lists, this is fine, because we can just assume that… well, not assume, we just clear the tree, and we assume it is empty, and we can all, all is fine.

The problem is that with the block access lists, we now create this, this extra execution mode, or, well, state applying mode. Where you do not execute your transactions, you just apply the state div. And this is problematic, because if we have a tree which is not empty, then if we assume it is empty, that this implicity means we are deleting all the storage keys which are in the original tree. The thing is that EIP8253, what we do with these accounts which are affected, these are only 28 accounts, these are the accounts of the type, they have no code. They have not zero. But they have non-empty storage. And by the contact collision test, I believe it is EIP684, we only check for the nonce, which should be 0, and that it should have, empty code.

But we do not check the storage there. So… from this point of view, we could see, like, this is my perspective, this should actually have been maybe, like, an addition to the BlockXList EIP. But maybe it's also Miss Kindle to do this here. The spec change, I think, is, like, fairly easy, because we only have to overwrite, like, 28 accounts, but they wanted to bring this up now. Because we should either ship it in Hegota or just now, and I think the cleanest way to do this is to, well. I know it is late, but, yeah, to do this now, because we normally have, like, this weird spec. And I see Toni with the hand up.

Toni Wahrstätter: Yeah, I'm not sure if I get, if I get the point, like, what goes wrong if we don't do it?

Jochem Brouwer: Okay, so if we have the book access list, and if we do… okay, so this is, again, like, this theoretical, scenario. Where we create an account on a account which has non-zero empty codes, and with storage in it. So, in the Block Access List, what should happen there is that we apply, that we delete all these original storage accounts, and you can see why this is a problem, because we cannot iterate over the storage tree. Because most accounts, they save the hash of the storage key, and for the book access list, we need the pre-image of the storage key. So, in order to create a block access list, which is correct, like, if you would not re-execute your transaction, but if you would directly apply the state div of your block access list, then you would get a different state root than if you would re-execute the transactions.

Toni Wahrstätter: Yeah, but this is, like, applying those very, historical transactions. This is, like, a pre-glimpse of them, where there is no Block Access List. You're, like, assuming you would create a block access list from Genesis.

Jochem Brouwer: Yes, I… I guess, or if you have, like, this hash collision, yeah, okay, yeah, yeah. Yeah, I see. Okay, I…

Toni Wahrstätter: Because it feels like there shouldn't be any difference, right? The Block Access List contains all theatives, and it doesn't really care what was, what that storage slot was holding beforehand. It's basically just the post state, so it shouldn't matter if an account was created without bumping the nonce while writing storage, or if the nonce was bumped. We would, of course, see, like, weird patterns. You could, for example. set a storage slot to 0 again, while the nonce is still… While the nonce is bumped to 1, and usually this would be bumped to 2 for every other account, but I don't see that there is any issue. I think this EIP makes a ton of sense, and we should have done it earlier, but I wouldn't, like, include it that late in the process, but to me, this feels like a no-brainer for Hegota.

Jochem Brouwer: Okay, yeah, Yeah, I think I agree. I just wanted to say that if we had this EIP earlier, then we should have included it in Lambda, but yeah, it's now very late, so let's include it in a code.

Spencer Taylor-Brown: I want to add really quick that I guess this is… Kind of a… a wrap-up after we… after we deified 7610. like, I… like, yeah, this… these scenarios kind of happened on the mainnet, but we ended up with, like. Clients differing again, in, like, a different way, and then we've had these discussions coming back again. I would also say it's really easy to test. Like, we just need a few transition tests and eels. I believe Nethermind already has an implementation. Yeah, it is late in the process, but personally, I'd want to see what, client teams… feel on this, or if it's too late for them. So if there are client teams that would be open to adding it, I feel like we should, but if…

If the consensus is Hegota, then… Yeah, let's ship it in Hagata.

Dragan Rakita: My opinion is I want… To finish this as fast as possible. If you can push it for Lambda then, that would be great. If not, I will propose it for… I think Hegota is, like, good timeline. I think it's good cleanup that should have happened a lot of time ago. So, I'm fine with anything. If people are eager to include this now, let's do it. If not, let's do it in Hegota.

Danceratopz: Nice. Alright. Thanks, Dragan.

Toni Wahrstätter: add… just to add, I think including it would also mean we would have to artificially add the launches to the Block Access List, too. So it's not just, A state transition, it's also adding to the block access list at the state. at the fork boundary. And this is not really something we had to do until now, if we actually proceed with that.

Jochem Brouwer: Yeah, just to mention my chat, this change to the block access list, that's in EIP 8253. So, how this, looks.

Dragan Rakita: For Lambda hard fork, maybe that's not a big of a deal. Maybe we can, like, assume the first block is going to miss those nonsense. But for Hegota, probably… yeah, we should include decidable.

Danceratopz: would some other client teams like to speak… speak to their preference for Lambda or Hegota inclusion? Let's, let's start with Nevermind. Is anyone from Nevermind here, and has an opinion to this? Seems too late. Is…

Alexey Osipov: It's been in…

Danceratopz: Yeah, please speak up.

Alexey Osipov: Pinto… Sorry, it seems kind of late. We will not have enough transitions to test it. Hopefully. Feels like… and it's a typical change, like, one time, it seems, It requires, it will require more testing to be confident. Well, that it happens properly. And we have no time for that. Seems like maybe other people from another mind will have other opinions, but… It… it's for sure, I think, to include the, you know, Hegota. At least.

Danceratopz: Okay.

Marius van der Wijden: Yes, that's from… I'm, I'm not super pumped. I'm not super familiar with this, because Gary has been handling this edge case, for us. My… Gut feeling is that… If we add a lot of, like, code complexity. Or, like, that code that we have to change in Hegota now, because of this. then I think it would make sense to include it, to, like, to get this out of the way. If there's… basically note that. no tech debt that we are… we are leaving behind, then I think it should be… probably be bumped to Hegota. The… Like, what I don't want is to…

To have to touch the ball mechanism in Hegota again, and to have, like, two different ball mechanisms between Lambda and Hegota because of this. I think that is what I mean with, like, tick the, So, I'm not sure if that can actually happen, but…

Danceratopz: That's a valid point on technical debt. Toni, do you have a feeling for that on the client implementation side?

Toni Wahrstätter: So this change, it doesn't matter if you do it in GetHotter or in Glamsterdam, we will always, at the fork transition, need to, like, interfere with the… with the ball. Because, we… we need… if we… if we do the state transition on disk, we also need to reflect that in the ball. So it doesn't matter, actually, why I advocated for, Hegota instead of Glamsterdam, just because… This interaction of pushing those items into the bar will also impact, Like, depending on how the block at the fork transition looks like. plus those items, the final ball will have a different shape. So it feels like there is some interaction with balls. that we have to, we have to, solve anyway, no matter if I get how I Glamsterdam, but if I Glamsterdam, it feels too late in the process.

Danceratopz: Thanks, Toni. Ben?

Ben Adams: Yeah, so… so an idea we dabbled with was, we could have, like, a fork block. Before the fork block, so like a pre-flock. And then… we do this transition so it's not in the bells. But that… it… we're… I think we're way too late in the process for that. And looking at the accounts, they're all fairly small. I think the max is, like, maybe… 40 storage slots, so it's not… putting them in the bell isn't, you know, it's not the end of the world. They're not like… We don't have to put, like, thousands of storage slots in. Yeah, so I'm just saying we can wait. It's not too much of a problem.

Danceratopz: Okay, thanks, Ben. Looking at the reaction in the chat, it seems that most clients do seem to prefer to defer it to Hoga to, in Consensus, it's a little bit too late. Thriding it here. Looking at the comment from, ivan from ethrex, and… The reactions from… Karim… On it being too late. So I think… Unless, Unless anyone else has some strong feelings or wants to follow up on this regarding Marius' question about introducing technical debt. I would say that it's quite clear that if… Someone has, a strong feeling, then we can… quickly check the impact of that, and make a decision on Thursday, but I think… Is there anyone in the call that feels strongly about looking at that, Marius? Did you want to take that up, for example?

Marius van der Wijden: Nope, I'm… I'm… I think I'm fine with… it seems like the rough consensus is to, unless, Unless something significant changes to just push it to Hegota. I'm fine with that.

Danceratopz: Okay, perfect. Thanks, Marius. Toni?

Toni Wahrstätter: Yeah, maybe we can just delay the decision until Thursday. If clients coordinate async, that it's good to do, then… Yeah, would be good if we… if we get it earlier than later. Of course, we have to be aware about potential more work, but maybe it's worth it, so… Because many people have heard about it, today for the first time, maybe. Delaying until Thursday would make sense.

Danceratopz: Okay, sounds good. So that, definitely removes the complication of it being a topic for DevNet 11, which definitely leaves it very late, but… we can perhaps make an informed decision on Thursday. I'll add it to the agenda for ACD. All right, okay. Thanks a lot, Joachim, for bringing that up. Is there any other comments? Did anyone else want to make? On that topic, before moving on. Okay, thanks everyone for that. Then… Last ACDT, we talked about, Pavel's, EIP837 self-destruct,

PR, and it was decided at ACDC to to not include it, I see it's still open. I guess everyone is still happy with that decision, and I don't think Pablo's in the call, so I can ping him. But if anyone had a strong opinion on that now, please speak up, but I think otherwise that was resolved. Last week. Okay, perfect. And we can move on to the next item, which is, Oh, sorry, I've skipped, so I wanted to just check in with benchmarking, whether anyone had anything important to bring up in ACDT today. Ready to sort of raise awareness for tomorrow's call?

It's spontaneous, but if anyone has anything… That they want to raise awareness for, for the benchmarking call tomorrow. Speaking of that. Jochem?

Jochem Brouwer: Yeah, sorry, I wanted to make one point about, this, stuff, what you just addressed. So, I've talked to, the people who are using this self-distance create pattern, and, They want to use this pattern, but we have concluded that we do not want to incentivize people to use a self-district. So this is also why we are doing these changes. But I've requested an ephemeral accounts channel on EF R&D, to help these people further with especially the, the opcode, the Create opcode, so EIP8360. To help them further with, with this stuff, and I just wanted to have that on the records that, we are looking into this, and helping these people out, so that they can make the CFP, and that we can ship this thing. Yeah, thanks.

Danceratopz: Thanks a lot, Joachim. That's great. Yeah. It's important that these people feel heard. It's just unfortunately a bit late in the process. We're changing that. Thanks a lot. Carlos.

CPerezz: Yeah,

Danceratopz: Your hand up.

CPerezz: Just for teams, if they want to get a bit more prepared for tomorrow, I will bring up the results on using jochemnet versus State Actor. I've been doing some explorations for GetH, And in GetH, in fact, the issue was that the jochem snapshot was actually the one that should not be used as a reference, mainly because it was loading from the journal a bunch of accounts and treating them as warm, and this is where the major performance difference was coming from. I don't think we're gonna change anyways, the numbers of 8038 according to that, but it's… more than likely that we are going to choose going for State Actor, for the next set of benchmarks, if we have to run any in Hegota and later. So yeah, just raising the flag, because this will be a topic that we touch on tomorrow's call.

Danceratopz: Awesome. Thanks, Carlos. And I think we can move on, if there's nothing else for benchmarking. Just give that another chance. If not, I would just bring up, Carlos can stay on the mic. Carlos wanted to bring up, the question of reorg testing on the EL layer. And what, well, I'll let Carlos ask this question, but I think it's basically asking what kind of requirements would clients have for real testing? Do they have any wishes on this topic? Carlos, would you… Please correct me if I'm wrong.

CPerezz: No, you're right, thank you. Mainly, the topic is related to this link, that Dan also shared. I think all EL clients were pinged, but we had no responses so far. We are working on, PBT, but I think this work will be useful independently of whether we do it or not. And it's… it's basically relative to the fact that everyone is testing reorgs on their testing suits, but there's no actual reorg, I don't know, general testing, or call it whatever, where we're gonna contribute and make sure that, we are testing everything that we should. And so, just to prevent issues like, that we could have caught, like the one from, the latest Rev fork on mainnet, for example, which was related to MPT, if I recall correctly.

It would be nice if we could work on something a bit more general that our clients can consume. And it was mainly to see if EL clients have any opinions or takes on that, if they are against or strongly against for some reason, and whether they have any preferences or not on using Hive or EEST, or I don't know, something like that as basis. This should not imply any work for them. We would be the ones doing it. But it's mainly to see if they… They want to say anything, before we start.

Danceratopz: Thanks, Carlos.

Marius van der Wijden: I…

Danceratopz: Did, yeah, please.

Marius van der Wijden: So I have a slight preference for Hive, just because, I don't… I want to prevent us creating another tool. With the same capabilities that we have to maintain, that we have to look at, so… since Hive has a bunch of sync tests already, and… there has… has been done work to do reorg tests on Hype, or there were reorg tests on Hype at some point. Don't know how… I'll, how good they are, or how up-to-date they are, or if they're even still there, but I would prefer to keep it in Hive as… If, if possible.

Danceratopz: Thanks, Marius. Any other client requests or comments on Rio Testing?

Ben Adams: Hive. Hive would be good.

Danceratopz: Okay, perfect. Thanks, Ben. Lewis?

Luis Pinto: Are there any performance, testing as well planned for that?

Danceratopz: That's a good question. So, I think my idea would be… the… so what I can see in the Golang execution simulator is that there are some riog tests. I think we can probably… if we move the format to a similar test format that we have in East. But that also allowed the test author to add FCU directives to their test when they'd like to have it. I think that would be… a good way of testing reorgs to allow… Very complex, scenarios to be made. And if we developed this within EAST, then the advantage would be that we could also potentially add benchmark-specific tests for this as well, because it would be in the same format.

So I'm not sure if Carlos had also thought about the… oh, he said yes.

CPerezz: Yeah, yeah, yeah.

Danceratopz: Perfect.

CPerezz: The reason is, if we support such a massive window where it takes us ages to do the reorg, I'm not sure it will… It will be extremely useful. And at least we have a way to measure how good or bad our client team's doing, so I think it's useful.

Danceratopz: Thanks, Carlos. Awesome. Okay. Nice. Alright, then, I think, I think, Carlos, you've got the answers to your questions. Perfect.

CPerezz: Thank you, everyone.

Danceratopz: Thanks a lot. Alright, the next topic would be, something that Stefan brought up last week, but unfortunately. Due to the busyness of the call, time ran out. This was about the EV72TX size being ambiguous for Type 3 transactions. Is this still relevant, Stefan? Did you want to talk about it today?

Stefan Starflinger: I can just quickly summarize it. I think most clients have already fixed it. It's just something that we can… if we want, we can clarify a little bit more in the specification. Because it's a little bit ambiguous, for, transactions of type 3, so I think that was blob transactions. Where the actual data is in the sidecar, and some clients were handling the size announcements differently, and were downscoring each other, because of… because of that. So they expected to receive a certain size. Which, they didn't end up getting. And I created a PR against most of the clients that had an issue here, and I think, yeah, it should be okay. But we can, if we want, define

Like I did here in this PR I will share. Kind of a more… I already shared, yeah, a more detailed kind of version, but it's still kind of like a… Work in progress. On how best to formalize that, and how much we should formalize. That's just kind of a small update. I don't think, there's much to discuss here.

Danceratopz: Thanks, Stefan.

Stefan Starflinger: Let's do a chime in.

Danceratopz: Yeah, thanks, Stefan. I was just wondering if you wanted to call out on anyone in particular for feedback there, to help move it on?

Stefan Starflinger: No, I think that's… that's okay, we can do that async. Anyone is free to just comment on the PR.

Danceratopz: Perfect. Alright, thanks, Stefan. That's pretty much it. One last topic, which is… More of a heads up, this is about, state gas and depot traces. This is also Comment from Stefan. I think, basically, it's a heads up that's going to be chatted about in 7 minutes in the RPC standards call. But if anyone can't make it, they could. Leave a quick comment here. Did you want to give a quick overview, Stefan?

Stefan Starflinger: Yeah, sure. I think a few clients have already implemented this, and I think Chase has also made a lot of progress regarding the RPC compatibility testing suit, and he's, I think, updated the Hive. Changes, now, so that it's, ready for cancer, and, This change is very glam-specific, so that you get the different types of guests from a trace. And it will be discussed, and hopefully finalized. In the standards call. And then we will have tests, hopefully for it.

Danceratopz: Awesome, thank you, Stefan. Marius comments that he'd like making it state gas execution. Is that basically, what you're suggesting, Stefan?

Stefan Starflinger: Or maybe Marius wants to, say something to that?

Marius van der Wijden: No, I have no idea, I haven't looked at the proposal yet. But I… Would like to make it a kind of a vector that we can add to… The more, things we are, and the more different types of, of, Of gas we are getting in the future.

Stefan Starflinger: Yeah, then it's pretty aligned with what you're saying. the PR.

Danceratopz: Perfect. Thanks a lot for the verification. Sounds good. Okay, Juan, That's it for the agenda today, I think. Let me just refresh the issue. That one posted in the meantime. Otherwise, did anyone else have any other topics for today they wanted to share before we log off? Okay, perfect. Then, thanks a lot, everyone. Have a good week. And see you next time.

Dragan Rakita: Bye.

Stefan Starflinger: So…

Jochem Brouwer: Bye-bye.

Marcos A. Maceo: Hi, guys.

Louis Tsai: Goodbye.

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