All Core Devs - Testing #43

Transcript

Mario Vega: I think we should be good to go. Do you want to move over.

Pooja Ranjan: Sure we are live.

Mario Vega: Awesome. Thank you so much. Hello, everyone. Welcome to Okra. Depth testing number 43. Today is July 7, th and we have 4 points in the agenda plus other comments that I want to touch upon. That people added recently today to the issue, I'll share the link where you want to take a look. Here's the link. And yeah, we can get started with Fussaka. This is the 1st topic. So I guess the 1st thing about Fussaka would be definite 2. And I see Barnabas is has joined. Do you have any any updates there.

Barnabas Busa: Yeah, sure. So has been on finalized during the whole weekend. Just late last night he managed to get back into finalization. I had to exit a few validators. This is due to the fact that Nimbusia was missing too many slots. And it was just a bit easier to try to finalize without them being online. There are still a few validators left for them and also had some validators exited. We are currently at 75% last time I checked. So we should be good to go. Prism had some sinking bugs that they are looking into right now, and also Tech, who had some nodes that were stuck but that was probably due to just insufficient memory. So yeah, lighthouse

also had a bit of issues with the Cgc values earlier on. But I think that has been all resolved.

Mario Vega: Thank you. Do we need any updates from the clients now? Of the open issues? And which ones did you say that need updating.

Barnabas Busa: So the major issues on Nimbo side was the status 3, 2 on Taku side. It was the thinking bug due to insufficient RAM that has been resolved. We just bumped the RAM of the Jvm. A bit the. But the team is still looking into possible syncing issues. Prism had the thinking issue during the non finality that has been resolved with a restart on during finality. So we might need to do another one or 2 non finalization scenarios where these bugs can be caught again. But right now they cannot reproduce it locally.

Mario Vega: Okay, it makes sense. With this in mind. Okay, thank yes. Matthew.

Matthew Keil: Yeah. Lodestar. We also found an issue lower level in a Liberty update that got highlighted during onfidelity. But we're getting that resolved.

Mario Vega: Cool anyone from prism or Teku that wants to give an update, or and maybe we expand on on the issues.

Emmanuel Nalepa: Yeah, I can. So for prism, yeah. So Barnabas, try to to reboot the node prism, node ring and finality, it seemed. And the node was stuck. Now the network is finalizing again. I cannot reproduce the issue. I mean just rebooting the node. Just we solve the issue when and the nerd is up to the asynct, up to the chain, up to the tip of the chain. Now, which is a good and a bad thing. And so, yeah, I cannot reproduce the issue on the net. Now, I try to reproduce the issue on courthouses. So just basically, I created a small network. And I created an finalization, and I cannot reproduce the issue as well. It thinks everything sinks normally.

That's all I have to say about this issue.

Mario Vega: Thank you. Anyone from Teku or Lighthouse wants to give an update.

Pawan Dhananjay: Yeah, I can go for lighthouse. Yeah, we had a bunch of sync issues initially, like Barnabas mentioned. And some issues with updating the Cdc values, the Cdc values thing has been fixed the sync issues we have started fixing them. But yeah, I think like, in part of fixing them. It was like we figured that the some of the issues were related to some clients giving us like when we requested them for call columns with data columns by range request. They were sending us empty responses when they did not have the data. which is like, sort of malicious behavior, because once we received valid blocks for that range. But we did not receive valid columns for that range, and we tried to

couple those 2 together. There was an issue, basically, because the columns were invalid at that point. So it was good sort of it was almost sort of like a malicious test case where peers were returning us invalid values. And we had to recover from that. So we had. We basically changed our sync to accommodate for that where we downscore peers that don't return us correct data column by range values. So once we started doing that, and we eventually started down scoring and dropping those peers. Our sync has improved, but we still have, like some stuff to do on sync. So like when I when I was testing this, the clients that I noticed where not returning values, sometimes the numbers.

sometimes teku and grandine as well. So yeah, I think this was like a good test for us as well, because we are sort of handling the malicious case now and able to recover from it. So yeah, just letting other clients know as well that they are returning empty values when they shouldn't be. Yeah. And we are continuing on improving sync at this point.

Mario Vega: Thank you. A couple of things on the spec side. Do we need any updates? Do you have any any? This consideration of returning malicious columns in the spec. Does everybody know.

Pawan Dhananjay: So sorry. What do you mean?

Mario Vega: Yeah, aspect test is what I mean. Yep.

Pawan Dhananjay: Oh, okay, I think it's hard to have spec tests for it, because, like, there is no set way to recover from this like at least on lighthouse. We basically eventually downscore the peers and eventually end up banning them. So I think this sort of case would be hard to test on a spec test, but I'm not sure.

Justin Traglia: I agree I don't. I don't think we have a spec test for this, and I don't really know how we would.

Mario Vega: Cool. Thanks. Oh, okay, then, on the on the side of the clients that we're returning this invalid responses, I think you, said Nimbus and Grandine and Teku. Is there any stance on whether they should? I don't think they should be returning this. But is there any comments on those clients. Maybe there's a a reason why they were running like this.

Pawan Dhananjay: And and like just to note also that some of this, like, I'm not completely sure that the other clients were also wrong in some of this points, because we could have been requesting data columns per range for for a range that is, before their earliest available slot. But like some of the some of the peer ids that I manually checked. those did have like a earliest available slot like we were making a request for some for a range that was after the earliest available slot, so like it could be an issue on lighthouse side as well. But like this is just very rough manual testing. So just noting that as well.

Mario Vega: Got it. Thank you. Okay. jumping onto there. There's a comment on the chat by Barnabas about the backfill implementation. Do we want to go into that topic. Any any anybody, any comments from the clients? About backfill? Or if you have more context, paranounce that you want to add.

Barnabas Busa: I think everybody knows what I'm talking about.

Emmanuel Nalepa: For prisma still in progress, not yet done.

Pawan Dhananjay: Yeah. Same for lighthouses.

Matthew Keil: Same for lodestar.

Mario Vega: Teku and Nimbus. Any updates. And one question from baritosh is whether there's any blockers on implementation that you have found so far, or it's just mainly time that is required.

Pawan Dhananjay: Think for lighthouse. We yeah. But I think for lighthouse. We had to make some changes in the database schema. Also to sort of introduce the earliest available slot and continuously update it to be able to send it to peers. So like we had to get that done 1st before actually doing the backfill. So that took a little bit of time. But I think this week we are focusing on the actual backfill implementation. hoping to get it done soon.

Matthew Keil: Yeah, for us. It was just the complexity of getting a debug for the Devnet but we'll try to attempt it, I would guess probably next week. I don't think we'll get to it this week.

Emmanuel Nalepa: Prism. I don't know. I ask internally to the team. I will get back to you as soon as I have a don't swear.

Mario Vega: Thank you. From the other teams. Any updates, if not, that's okay. We can follow up on the next call alright. Any other topics on Devnet 2 that have to be touched. mainly asking because whether we want to start asking whether we want to schedule them in the tree, but I don't. I don't feel that's the case. Barnabas, do you have any opinion on the planetary or.

Barnabas Busa: I've shown you we need. I I think we should have a very stable devnet 2, before we even consider scheduling definitely. There's so many bugs to iron out and jumping on to definitely right now would be bad, in my opinion.

Parithosh Jayanthi: I guess at that point. Did we actually fix the bugs in Devnet, or did we patch them with validator changes.

Barnabas Busa: It's all patched. None of them are fixed.

Parithosh Jayanthi: Do we have a look what bugs need fixing them.

Barnabas Busa: That's the thing that Manu mentioned that during finality he could not reproduce the bug. So we're gonna need to do another non priority test.

Parithosh Jayanthi: Okay. Sounds good.

Mario Vega: All right. Thanks, and maybe it's time to bring another topic that was brought up on Acde, which is the 4 Kd issues. I believe, right? So we had this discussion on Acde that we wanted to introduce eap 7,910. I'm gonna link it in the in the chat. And basically, this is it underscore, configure, endpoint? Thank you. Do. We have an update on that from the teams? And I can, I can start with with testing side. We have a new command to test this. Basically, we're just lacking the configuration now. But this is this is something that we have to address with the Itband Ops team. But this is simple enough, but the main idea is that we are going to be testing this for all testnets and devnets inside of East.

And the main problem that I notice while implementing this on. on, on east is that it doesn't include the fork. Id, if I understand correctly. and I think this was the culprit from from the issue that we found on acde So with that in mind. What's the status on the teams, and opinion also on on the inclusion of this eap? Does anybody have time to implement it?

Barnabas Busa: Could we actually add fork id. To 79, 10.

Mario Vega: I mean, I think it should be a simple change. Maybe either add it to either underscore config or add another endpoint, but I don't have a preference over either. It's just a matter of how easy.

Barnabas Busa: Why would we need a different endpoint.

Mario Vega: Yeah, I'm not sure it's just it's just just an idea. Yeah.

Barnabas Busa: I personally feel like it. Config would be the perfect place for fork ids as well. So I would just extend the 79, 10 with a new field for fork ids, and just list it as a as an array.

Mario Vega: And one comment from Besu is that the current hash in eap is the 4 Kd. I'm not sure to be honest. Does anybody have the precise answer to that is current cache in the eap, the same as 4 kd. I don't think it is because it includes the precompiles, which I don't think 4 Kd. Ever considered. My guess is that it's not, but anybody else has.

Lightclient (Matt Garnett): I went fork id is the same as what.

Mario Vega: There's a there's a configuration hash in eap 79, 10 hit config response. But I don't think it matches for Kd. So the idea is, you have.

Lightclient (Matt Garnett): Yeah, I'm not familiar with that one. But fork Id definitely doesn't have the precompile. All it does is accumulate the fork block number in the genesis hash.

Mario Vega: So if you want to also verify fork id using it underscore config, we need to add another field right.

Lightclient (Matt Garnett): I'm not sure what information is provided by that endpoint.

Mario Vega: Okay? And Gabriel mentioned that they they cannot. The 4 Kd change to the eap. Awesome. Other clients. Does any? Does anybody else started to implement it. Underscore config. Never mind, get Aragon, please.

Alexey Osipov: This week.

Milen Filatov: Yeah, we added this in Aragon today, actually. But we will need to add the fork id in there as well.

Mario Vega: Thank you. I will wait until for adding 4 Kd, until we have the eap change. Just so we have the same format. Yep. Okaysu, never mind. Already have something does get, have any updates on on this endpoint? Yeah, yeah, thank you.

Lightclient (Matt Garnett): Have not implemented it.

Mario Vega: Okay, thanks. Who am I missing anyone from? Reth? Thank you. Alright. So it seems like, most of the teams are planning to implement this week, and we're gonna add the fork id into into the same endpoint, and we'll have a and best. We'll have a Pr for the eip. Cool. Okay.

Anders Kristiansen: That's right.

Mario Vega: I think we can move on. And the next issue, just give me one second. All right. Yeah. So the next point. And we touched upon this last week. So I just brought it up to this week is the gas limit testing updates. Does anybody know about the benchmark updates that we had in the previous week that could give an update.

Marcin Sobczak: Bye.

Mario Vega: See Joachim. And yeah, okay, thank you.

Marcin Sobczak: Yes, I can say about our results from our gas benchmark tool. And generally, we have, like the bottleneck is modex. There is a proposal to to increase the pricing aggressively 3 times. But there is still one edge case scenario for gaff and argon it's with based on modulo equal 22 Byte and exponent 64 bits. And from what I know, clients are work working to optimize it because there is a strange issue. And we have scenario with exponent, 64 bits, which is slow and with 65 bits it's like 50% faster. So it's probably some implementation detail which should be optimizable.

and except of modex, we we found that our test case for point evaluation precompile were broken Alexi delivered me like the valid input data for it. And right now we see that all the clients are operating at about 32 megas per second, which is like close to minimal requirement for for increasing that limit to 100 million. So it wouldn't be a blocker, but it would, it will be for anything above 100 million. And there is also probably some issue with Ref. But we are not sure it's like. On our dashboard they have only 9 megas per second. But when we took a look on the raw scenarios. It's like on August limit, except 60 million, and they are performing like other clients. And there is must be some edge case at exactly 60 million gas limit where they're slow. And

yes, it's reported to to Rev. Guys. And they are taking a look and and probably for Fusaka we like. There is nothing to do about this pre compile. But we need to be conscious that going above 100 million gas limit it will be a blocker for going above it before the the next fork. And I think it's it's all about the updates from agony testing.

Parithosh Jayanthi: Yeah, maybe to continue we also have the bloat net effort. So we have about one and a half times the state of Mainnet, and I'm working on setting up a public network there. And once we have that, we'll run a bunch of sync tests and a few tests like with Zen contract, so we can get a baseline on how it look like look like with one and a half times the state of Mainnet. And once that's there, we already have the spamming tools in place to continue increasing the state, and we can observe how stuff degrades over time. But that should be ready, probably in the next day.

Mario Vega: Thank you. I see there are a couple of open prs for repricings. I shared one in the in the chat. Does this need to be merged for Demo 3, I think, is your Pr or, yeah, modex.

Marcin Sobczak: Yes, so probably if if we don't want to So if Kevin probably are not able to optimize enough without changing libraries, and we don't want to like it's not probably not good for for in general to to use the same libraries in our clients, so if they will keep they they once probably they're not able to optimize enough to not be a blocker for 100 million. So in this case we just need to. To to increase the general price prices, and in the current shape of this eap only till the 8% of the calls are affected. If you want to to increase the pricing, then 100% of calls would be affected anyway. So if we if we do it, then, in my opinion, we should do it like significantly so. This Pr is proposing like free xing it.

And but there is still this one at case issue. Which they are taking a look at. Because it will be still too slow even with reacting. And there is like not not a good way actually to to solve it on, on like pricing area. We would need to to increase like minimal gas to to 1,500 or something like that. So it would would be great to to take to take a look at it and and try to optimize because it should be optimizable. Yes, and I think that's it. Do. Do you have some more more like more questions about it, or some specific areas.

Mario Vega: No, not really. I just wanted to move the conversation on on whether we have to merge or not. Marius.

Marius van der Wijden: Yeah, I can. I can speak on the problem, is that But yes, it's optimizable. The problem is that it's that we are depending on the Go Standard Library. So we would need to optimize the Go Standard Library and the problem with that is that yes, we can do it, and we've done it before, like we we upstream. Some changes to the ghost in that library, but it takes us like. yeah, kind of 2 releases of the Standard library for this to trickle down into the client. And so, yeah, it's it's it will take a long time until this.

Parithosh Jayanthi: Just also surfacing a discussion. I think we already agreed to merge this pr in as per acd last week, so is there any blocker to go ahead with doing that. I think we wanted to wait to see if we can do some outreach and make sure that no one's affected, and if that is true, then we would go ahead with merging right.

Marcin Sobczak: Yeah. So from my side, we can merge it as it is. I generally need to update or the descriptions, and, like the other parts of the of this eap. But yes, like it will not affect like the the equation. Just the cosmetic side of of this. Pr, so I I will do it like, you know, I can do it in another one. And like one last problem with this reacting is that we we are. We know that we have one case which is still too slow even after that. And yes, would be great to

Parithosh Jayanthi: Just to confirm, but it'll it's still just too slow for going over 100 million right.

Marcin Sobczak: Yes, I don't remember the exact number but there is a scenario scenario which will be below 30 mega gas per second for sure. It's right right now, like, without free acting. It's at 18 mega per second. Okay, I will do a quick calculation, and I can, I can give you the exact number in a moment, just don't want to to block the conversation right now to calculate it.

Parithosh Jayanthi: No worries. We can also do it. Offline later, if you want. That's perfectly fine.

Mario Vega: Yeah, I think Tim mentioned that the feedback he got is minimal impact. So we should be ready to go on merging this. So if you can just put together the change that you want to do the cosmetic changes, and we can move it from draft to open, so we can review it and merge it. That would be great. Yeah.

Marcin Sobczak: Effort can do it.

Mario Vega: All right. Awesome. Thank you. Good. Any other discussions on gas that were left out from Acd that we have to touch today. If not, we can move on to the next topic. Which is Peer Das. And there's just one comment on on the on the issue that is worth discussing whether the Cls will be trusting blobs from the El or not, and reading from the comment in the issue is that lighthouse and nimbus currently they do verify the blobs that come from the Els. But Prism and Teku. They trust them.

and there's no response from both star. So is there anything that we have to discuss there? Do we have to like reach upon agreement whether this has to happen the same way across all clients? Or is this something that is okay. If it's like implementation details. Francesco.

Francesco D'Amato: Yeah. So we definitely don't need to reach agreement. The reason we're talking about it is just that it's kind of a it makes a big difference to to decide to trust them or not, because, if you like, when you're building a block, let's say you get 50 blobs, or whatever. Now you have to verify all of them in the critical path of building a block and same thing for forget blobs. So it's kind of I don't know, like a few 100 ms extra that you don't really need there. So I think it would be best if we just agreed that there's no reason to be to be doing this. And all clients just drop this extra verification, because Al has already verified all these things.

And yeah, like the yell could also give you an invalid payload. So it's which you cannot verify. So it's it's not that, really. This is protecting you even from a malicious yell, if that's something that we're worried about for some reason. So yeah, on the side of like, do we need to all have the same implementation? No, but I think it would be best to just not have this verification. I think it's it's quite expensive.

Mario Vega: Yeah. Pardon.

Parithosh Jayanthi: Yeah, maybe just to follow on that. I also didn't particularly get. Why, Cls are reverifying. To begin with. And I wanted to understand if there was some particular reason, mainly because I also agree. The El in general, like in general, the engine Api has a trusted assumption like you expect that the El behaves non maliciously.

Pawan Dhananjay: Yeah, I think for us, like, the engine get blobs method like verifying stuff on that like, at least get get blobs. v. 1. We mainly did it because it wasn't that expensive, at least with 6 blobs, whatever we have right now. But yeah, like others pointed out with the with pdos, it will get more expensive, and it doesn't make sense to do it. But like for the main block production flow, I think the reason we do it is because we want to verify Kcg verify blob blobs that we receive from the builder. It is not mainly for local block production, but it is for verifying builder blobs. But like, because both of the flows are like the local block production and the builder flow are sort of interlinked, and it wasn't as expensive before peer does. We just did it for the local block production flow as well.

But we would also probably avoid doing that for paid us.

Mario Vega: Francisco.

Francesco D'Amato: Yeah. Same same comment as Barnabas in the chat. I don't really get even in the builder flow. Why, it would be important to to verify them again, for the same reason that the builder could also just give you an invalid payload. And I mean, you literally don't even have the payload, so you don't even have a chance to verify it.

Pawan Dhananjay: Yeah, that is a good point. Yeah, I think we'll talk a little bit more about this internally. Yeah, that's a good point that like we cannot verify the payload at all, so it doesn't make that much sense.

Mario Vega: Cool. Thank you. Okay, I think that's that's all. Unless there's comments from Nimbus, who also trust the blobs. If not, Sunnyside has comment. They wanted to add, standardized el metrics across Els for Demon 3. Would you care to expand on this?

J Sunnyside Labs: Yeah. Hi, so we have already been discussing for a while while back. And we now got ethereum repository for it, and then I just made a Pr for get blob speed to metrics. So if you guys have some time, then please have a look, and hopefully we can get it done by Devnet 3. Then we can get get some useful data for it.

Mario Vega: Thank you. Alright. Cool. Any other comments on Peerdas updates. They want to touch upon this this this call. All right. If not. There's 2 last comments on the issue that might be important to take. Take a look. So the 1st one is by Spencer. he's proposing to increase the gas from Clc. Of growth from 3 to 5 or 8. But he mentions there's no no current benchmarks. But yeah, if you want to do you want to raise comments on this, or expand on the idea.

Spencer Taylor-Brown: Hey, guys? Yeah, I guess. I just, I just figured because we don't have benchmarks for Cov yet, and because we probably want to finalize it for sake spec very quickly. and it might be nice, or at least safe, just to increase the gas cost from 3 to slightly higher and and kind of like with the our kind of like with our one, we can always reduce it again, and Amsterdam.

Mario Vega: I think, yeah, okay, thank you. I think the appropriate way would be if we can raise an appear in the eip for it to get get approved and merge. Do you want to take care of that? Or.

Spencer Taylor-Brown: I guess. If everyone is happy with that, or if anyone doesn't want to do that, then yeah, I mean, we can also wait, I guess, some days and get benchmarks, but just to finalize for cycle faster. This would be the only the alternative.

Mario Vega: Thank you. Ben.

Ben Adams: I I don't. I don't have any objections if people want to go for it. But also I just like to highlight that unlike. Say so at the moment. It's priced the same as add. but it's a single stack operation, so only pops one value, add pops 2, and add is then multiplier, quite complex instructions, and it's fairly simple. But I don't wanna block and increase it. That's what people want to go for.

Spencer Taylor-Brown: My gauge is that it will be well, yeah. it'd be be much more efficient than that in general. But yeah. I just it. It feels safer. But yeah, if if there's no objections, I can open the car.

Mario Vega: Yeah, I think barnabas mentioned that it should be a better way to go if we open a Pr and then proceed to add benchmarks to it. So I think that's that's a good way to go. So basically open a Pr in the eap and then just comment on it with the benchmarks. We wait for approvals, and then we can see if if we get merged.

Spencer Taylor-Brown: No sounds good. Can I just jump in really quick as well? And I guess suggest adding, like benchmarking requirements to the process for eips. and before the C. 5, because I guess the we've had our one and also Clc. When you upload a new precompile to me, it makes sense that we have some kind of benchmarking requirements before we add new precompiles or uploads in the future.

Mario Vega: Yeah, this is a great suggestion. I I guess the place where we can put that is in the yeah. Tim mentions it before. Sfi, I think I think I agree to be honest. We have a better benchmark infrastructure right now that we than we have a few months ago. So I think it should be it should be. It should be safer to to impose this this requirement. And Tim mentions that open a Pr to 77, 23 aip which basically jails. Sorry specifies the the steps to follow before Sfi and something. So yeah. yeah, I think we should, we should definitely open up here for this and and mention that we requires benchmark benchmarking to be done before Sfi

and Yay. yeah, if you want to go ahead. I think it should be a simple, simple peer. Yeah, cool. Okay. Thanks. Great. And one last comment from Ben. do you want to make a case for for this on your comment of eap, 7,983.

Ben Adams: Yeah. So there's a proposed. There's a there's a new eip from Tony to change the transaction cap to 16 million rather than 30 million. It seems to make sense to and bring that forward to Futaka rather than no wait and wait an entire work to bring that.

Mario Vega: I shared the pr in the chat.

Ben Adams: Yeah. And I, I mean that also resolves issues with, for instance, the Zen contract that we were looking at.

Mario Vega: Yeah, thanks. I think I guess my main concern with this is that this is basically a new aip, and I don't know how late in the process, are we? I I think, pretty relates or.

Ben Adams: I've I propose changing it into modification of the current one. because we're introducing the we're already introducing the transaction cap. and there was discussion whether it should be lower at the time. But since we didn't have any analysis. how much we could lower it to.

Mario Vega: I see. Is there an a Pr. Open for this specific one for eap? 78, 25.

Ben Adams: Yeah, put it in.

Mario Vega: Yeah, yeah, okay.

Ben Adams: Yeah. So at the moment we, we have the transaction cap going into Fussaka at 30 billion. Yeah. And then, rather than have a new eip cellar in the next fork. We might as well, Laura in this world got it. Got it? Change the existing one.

Ahmad Bitar: It's it's just a constant change like we're introducing transaction gas limit cap already in this fork. So if we know that the cap that we're sitting in this fork is not the correct cap. Why wait until next fork? Like, if we are, gonna do it, let's do it right from the beginning.

Mario Vega: Yeah. Makes sense makes sense. So the author of this pr, is Tony. I don't believe he's here. But it wouldn't. It would be nice to to ping him to, in my my sense is that we.

Toni Wahrstätter: No, I'm here.

Mario Vega: And just open a new oh, sorry, Tony! Do you want to expand on? Why, the new eap? And rather than.

Toni Wahrstätter: Yeah. So so I was creating this new Ap, just because I thought Fuzaka is already frozen and 7 MA. 25 might not get. Yeah. The gas limit kept low enough where we should get it to. It feels like for polarization, also for distributed proving. It might be beneficial to lower it even further. And I did some quick analysis. I have not published it yet, but basically, even if you lower it to 16 million. only 0 point 3%. The transactions will be affected. And 90% of them is Xen. So it's essentially yeah. Putting a cap on Xen.

Mario Vega: Got it. Got it? Yeah, I think the consensus seems to be that we want to make a Pr for 78, 25, instead of making a new eip. Is that correct? Does anybody have any objections to that?

Barnabas Busa: My argument is that this is kind of like a repressing change. So it's not a significant protocol change. That's why I feel like this could still make it into Fussaka without any big issue.

Ahmad Bitar: I remember Matt from Geth. Had issues with transaction cap as a whole, but I don't know if he would have an issue with lowering it even further. Matt.

Lightclient (Matt Garnett): Yeah, I mean, I think ultimately, my fear is something that's not happening on Mainnet today. I wonder like what the trickle effect will be if L. Twos are adopting l. 1 directly where there's a lot more activity with accounts, abstraction bundling. I mean, if this is what people want to do then. obviously not going to stop. It seems all right. They can always split the transaction into multiple transactions. My only comment on this more broadly is that when we make changes, even though this is kind of a repricing, it's not an issue for clients to do. But when we make changes at this point in the development cycle. We don't really give the community any time to give feedback on this. And this is something that could be

pretty impactful to people. And yeah, you know, we've done this analysis. There's only a handful of transactions that are impacted. But there could be people who are building companies or projects based on this these assumptions. And so if we make this change today, then there's only like maybe one month where there's someone could voice that this is going to impact them negatively. That said, I don't think we should stop. I don't think we should avoid doing this. It's just something that we need to consider. It's not always that it's easy for us to do. It's also that it needs to be legible and accessible for the community to put feedback on.

Mario Vega: Any response to that comment. I think it's reasonable. Yeah. The the downturn effects.

Ben Adams: I mean most most examples that we've we've looked at, including what was it? OP stack upgrades? they can be split across multiple transactions. I think it makes it messier because I think IP stack needed about 9 million or something. So it was sort of raised and discussed previously when we were talking about lowering it initially, trying to find the the right value. And then we went with leaving at 30 million. Because. yeah, that was an urgency to find the value. And it seemed like, we'll just leave it. However, with the issues it runs in that we've discovered. If we want to go to higher gas limits. and it's better to split the transactions that are dismissible. Anyway.

Mario Vega: Okay? So I think the consensus would be that we can go ahead and open the Pr. To the to the original eap. Tony, is that is that is that okay for you. Do you want to open the Pr, and then we can start the discussion there.

Toni Wahrstätter: Yeah, that's fine.

Mario Vega: Cool. Alright. Thank you. Any any other comments any other topic that we should touch today?

Marcin Sobczak: I will. I would like to say a bit more about modex. If I can.

Mario Vega: Yeah, sure.

Marcin Sobczak: So I did some rough estimation, and after 3 x in the price, our worst case should be at about 31 mega gas per second. So it would be like close to our minimum requirement for 100 million gas limit, but would be great to test test it instead of estimating so I would like to ask all your client teams to push this change to the performance modex the branches so we will see the results on the dashboard like the exact results, not estimations especially important for Jeff, and as like, it's most interesting how it will look on for them.

Mario Vega: Thank you. Any objections to this? all right. Any other topics. Does. Anybody else wants to write raise today? Cool. And Mario comments that Mario's comments, said he, will push the change as soon as possible. All right, thank you. Well, if nothing else, I think we can end the call here. Thank you. Everyone for joining, and yeah, have a good rest of the day.

Lightclient (Matt Garnett): Thanks.

Toni Wahrstätter: Thank you.

Justin Traglia: Cheers. Bye, bye, everyone.

Andrés: Bye.

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