All Core Devs - Execution #211

Transcript

Tim Beiko: okay, I think we could probably move over Pooja.

Pooja Ranjan: We are, live.

Tim Beiko: Thank you. Welcome everyone to Acde at number 211. Lots of people added stuff on the agenda in the last few hours. So yeah, I just I just re scrambled it together. But 1st off we'll discuss Petra, which obviously went live on on Mainnet yesterday. Then a bunch of stuff related to Fusaka. There were also some spread about measuring State growth and getting better metrics for that. And then, if we have time. I shared my thoughts yesterday around how we should potentially improve the awkward Devs process, and someone else also, had that post about building better tooling for that and if we have time, after all that there is also another eip that someone wanted feedback on

But to start yeah, Petro went live yesterday. Congratulations. Everyone. It seems like the fork went smoothly, and there weren't any major issues. This is huge. It was the biggest work in terms of eips that we've shipped. I don't know if anyone has any like status update or or yeah observations they want to share about the fork. But it. yeah, from what I could tell, it went pretty clean. Okay, well, yes. Guess we can leave it at that. again. Yeah. Congrats everyone on getting this shipped. It was a lot of work. And yeah, it is live. Yes, onto the next one. And then, if you're listening, you can try out all the new features like Max, TV, 7,002, and the Bls precompile on mainnet I'll also give a shout out to the testing team for a new thing they did for this fork. So we obviously have all these execution spec tests. We tried to identify which subset

which subsets we should actually run on Mainnet. And then we ran like some of the actual spec tests on Mainnet to test the eips and prod as well. Yeah, to sanity check that. There were no issues on my net. so yeah, new thing we've done when testing this fork. and yes, we could also pick it up today if people feel like. But yeah, okay, moving on to Fusaka. So like we'd discussed a few weeks ago. Going forward. We wanna kind of use awkward devs execution, and Cl. Calls to work on scoping and and debating the next forks. And and with Petra done this means the Fusaka kind of implementation. Conversation should move to should move to the Acd calls that we have on the Mondays.

And so going forward especially for pure dos, we will be using those calls. So there's currently appeared as breakout scheduled on Tuesdays, and I believe, starting next week, it will move to the Monday call. Is that correct? In terms of dates?

Will Corcoran: That's correct.

Tim Beiko: Okay, great. I cause I just look at the calendar to. There's still the period as breakouts on the Tuesday in the calendar. So we should delete those. But yeah, Fusaka is now the next fork and yeah, we can. We can continue the conversation there in a Cdt on the El side. So what we spoke about the last 2 calls was this idea that we wanted to focus on increasing the gas limit. And it's kind of a weird thing to put in the fork, because the hard forks or sorry the gas limit is is not set in consensus. It's set by the the block proposers we still wanted to have, you know, some sort of forcing function or reminder to prioritize this during the fork. And so we came up with this eip to increase the defaults at the Fusaka Fork. The idea being that we would

we we would effectively work on, you know, getting through the bottlenecks that that prevent us from from raising the gas limit. And then we And then once we get to to Fusaka and and ready to deploy that we would change the placeholder there for an actual number. So it's kind of a weird vip, because it just says, like we should do stuff to increase the gas limit. But then, the actual, like semantic change, is just a constant in the clients, but it does feel like the best way to encapsulate that we actually want to do this work. so I know, like it. I think this was either the last call or the call. Before that we said we would specify something like this.

yeah. Wanted to give people like a last chance to comment. yeah, Micah.

Micah Zoltu: So I feel like the arguments against this differ greatly, depending on what the increase is to like. If the increase is to 36 million as a default. That's probably not really contentious. If the default is changing to like a hundred 1 million or 500 million or a billion. The arguments are very different. And so I'm curious.

Tim Beiko: I think how we can approach.

Micah Zoltu: Are debating.

Tim Beiko: I think the rough target is something in the 100 ish millions and it's hard to know but like, and the eip has like a you know, 3 figure 1 million placeholder. But yeah. and and yeah, a hundred 50 is like a number we've used. But the idea is like, maybe by the time Fusaka ships we realize, like, you know, we can't actually run 115 the clients comfortably and like, maybe you know, the clients are able to run at like 95 million. And perhaps we want to recommend some value before that below that. So we might say, like, okay, we're comfortable. With 95. We'll set the default. So like 85 or something like that.

Micah Zoltu: So I think my main concern, after talking to people about this, that I think I would like to see more work on is in all the discussions around the gas limit that's increased. I've seen the discussions focus around what a validator or a builder can handle. I see very little discussion around what an Rpc. Provider can handle and what they should have to handle, the idea being Rpc. Providers right now are people like infura and alchemy, but ideally they would be end users running ethereum on their local machine or at home. And these people are a very different demographic than the people who hold 32 Eth. And have, you know, dedicated servers and operations, budgets, etc.

And so I would like to see sometime before we make a decision. I'd like to see much more discussion on how a gas limit will impact these people. Something to keep in mind is that pure Das and statelessness and history deletion. Don't help Rpc. Providers at all. Rpc. Providers already delete most of their history. They prune their state like they're running as slim as they can, and state growth is like the only thing that increases their disk significantly. And these, you know again, just would like to see more discussion around them and less discussion around the people who have giant machines that are beefy and able to do lots of stuff.

Tim Beiko: Thanks. Anzgar.

Ansgar Dietrichs: Yeah, I just wanted to say, I think these concerns are very valid by Micah. I think it's good that they're being brought up. I think we should kind of have the clear separation, though, like for me today, is much more about deciding that directionally. We want to basically keep pushing, keep keep exploring what the kind of safe throughput numbers are, and then what the bottlenecks are and keep working on those. So it's really much more about like agreeing on the direction and on the process, and then within that, I think this this is exactly the type of question we should ask right, like, once. Once we actually are serious about having that continuous loop getting more sophisticated about like, what are the different node types that we aim for? What are the different bottlenecks we pay attention to. I think that makes a lot of sense. But like I would, I would separate that out right today is much more about like saying the direction is to try to scale.

Tim Beiko: Thanks. Francis.

Francis Li: Yeah, Hi, I'm not sure if it's like, completely, a hundred percent like exactly you can imagine. But for example, for base, we're at like 140 million gas per block right now, at 2 second block time. And Rpcs are fine. So just a data point this, obviously a little bit different on hardware spec and different stuff. But yeah, just a data point. There.

Tim Beiko: Right? And I guess, like, yeah, maybe you might get to your Rpc point is, is your is your concern like if I'm running a node on my computer. And I want to serve an Rpc. To others, or just to process my own transactions through my own Rpc. Endpoint.

Micah Zoltu: I think those are 2 different users. Both of them should be considered. Certainly, for example, a Rpc. Provider probably runs by far the most like CPU burn of anybody, because people are constantly doing Eth calls, and that includes also, you know, doing lots of state lookups like someone like Infera. They have to have a, you know, be able to deal with huge amounts of random access on their disks versus someone who's just running on their local computer. They're doing very little work like the actual work is very little. But they also don't have the benefit of having petabyte drives. They can scale across. And right that yeah. So 2 different 2 different classes of users, I think both are important, and both should be discussed.

Tim Beiko: Right, but I think like I guess the Francis Point, like, you know, infer will be fine. Like they run other chains, they already, you know, like, do that. And then the question of the likes, you know, local user is more, what is what is like the performance degradation of their local Rpc. Access with a larger state. It's probably the question to answer.

Micah Zoltu: But I don't think so. I think the performance of a local machine, I don't think is going to be the bottleneck. I think the bottleneck is going to be the size of a hard drive. Your average user has the average user, you know, even a gaming rig. You get a 2 TB drive, maybe. And it's 50% full of games. And so you've got another 25% for your OS and your music and your videos. And you're down to like 512 GB. And so the question is, how fast is that going to fill up? And whereas someone like inferior, they probably don't care much about the disks at all. They care a lot about the CPU burn and the disk. I/O.

Tim Beiko: Correct. But do you think that? Okay, so do you think that for home users this size is effectively the biggest constraint for State growth.

Micah Zoltu: For the people I talk to who try to run ethereum clients on their home machines. Disk size is the number one bottleneck. These people usually have gaming rigs. So the processing power is not a problem. RAM is usually not a problem. It's always the disk, like the disk is the thing that they just don't have, and they have to go out of their way to buy.

Tim Beiko: Okay? So I think, okay, this is a tractable thing. So I I would separate those things, though, and I don't think that we're like anywhere near the performance. Bottlenecks of, you know, infra not being able to serve Rpc access. But like, yes, this, the disk size is a concern. I think Marius was next.

Marius van der Wijden: Yes, so I am kind of against this eap, because I think it would. It would not be wise to push for a higher gas limit as long as we don't have the state growth solved. Right now, we're status roughly growing by 5 GB a month, and so going to 60, a million gas will grow the State by 10 GB a month, which is 120 GB a year. Yes, there are other chains that are doing, having a way larger state, but they also engineered their stuff in a way that they can handle it. And the way they engineer. It is. Everything kind of becomes trusted like they're getting a lot of trusted. They're getting a trusted snapshot from some trusted party, and they're not verifying transactions anymore. They just apply the state updates.

And so yeah, we should be. We should. Only I think we should only really increase the gas limit. Once we have a way of once, we once we also decide to increase the cost of storing stuff. Which in turn would make would make execution cheaper. and and and storing more expensive. or we could introduce some new mechanism of of State expiry or something. But we we aren't really there yet, because the the workaround State expiry is not great, so the problem so so as Dom just mentioned in the chat, 120 GB a year is not is not too bad.

or it's not a problem. Yes, it's true, but size wise. It's not a problem. And the problem is that random accesses in this in this data will get much worse. So we kind of saw, we kind of had some benchmarks recently that we're currently the way, the way our database is architecture with pebble. We we kind of hit a wall at a data set of like 500 GB. So random accesses in a data set of 500 GB. It's kind of where we where we kind of hit the wall where state access get extremely slow. So yeah.

Tim Beiko: Thanks. Let's do, Dunkrat, and then Sophia.

Dankrad Feist: Yeah. So I think on the Rpc notes, I think my my opinion is that the reality is like, I think it's just time to look at what's actually happening, and that is that the number of ethereum users who run their own nodes and like use it directly through that is already extremely low, and like continuing to double down on a strategy that hasn't worked in the past is just. I think it just doesn't make sense to me like, I think, like our our real like, our real strategy around like running your own node has to become like something around verifying a zk chain and using some other way of like like retrieving the State trustlessly for that. And

I don't think we should continue optimizing. Oh, users should run their own Rpc notes that keep the full state. So I think, like it's it's just like it just doesn't make sense to keep doubling down on something that hasn't worked, and we've already like now sufficiently increased, like the cost of running notes that I think, like the number of users who like on the side run like a node without being very dedicated to it, is already like dwindling.

Tim Beiko: Thanks. Let's do, Sofia, and then answer again.

Sophia Gold: Yeah, I agree with Ankara that we shouldn't optimize for a use case that essentially no one is doing. For reasons that have nothing to do, I think, with hardware requirements, but mainly I wanted to say that I don't think that we need to block on block increasing the gas limit on concerns about state growth. Because we one, I mean, we do have time. For example, in Glamsterdam we could increase the cost of fresh storage rates. And we do have, I think, a credible medium term, stateless plan. maybe not in time for the State reaching half a terabyte, which is, I think, is what Maria said. It slows down significantly. But I think we could have zk clients on Mainnet next year. And you know we we could make them required, probably a couple of years after that. So,

you know, we do have a plan to deal with this. I think as long as it as the the pace of State growth matches that timeline.

Tim Beiko: Right? And I guess one question I'd have like following up on what Marius said. Here is obviously, random access on a larger state becomes more problematic. So yes, if we make, like new State access. extremely expensive, but then accessing the existing state constant and grow the state? Is it a problem is like more access across a smaller state within a given block size as problematic. Yeah, I don't know if anyone has an intuition for that. If not, this feels like something practical. We should test like, yeah. How's it going.

Ansgar Dietrichs: Yeah, then, maybe on that point, just very briefly, like, I think we as we start scaling the gas limit. Probably we should more regularly. Just do rebalancing of guest cost right? Where basically, like we if we say we are comfortable, that we have a lot of headroom in, I don't know. Call data, or we have a lot of headroom in state access but not state growth. Right? Then we should just like, be okay with in a hard fork. literally just 5 xing, 10 xing. The cost of state of one specific kind of type of usage, so that we can just scale everything else in the meantime. And then, as we unblock these things, we can then later on, make them cheaper again. And you know so like, I think that should just be a continuous loop rerun on every hard fog. The kind of point is just that these things, of course, then, have a pretty long lead time, whereas, like a lot of other things we can do.

I don't know changing the database or things like that. Of course, that also takes time, but we can do that whenever pricing we can only change at the Hard Fork, and of course it has to be locked in like many months in advance. So, for example, right now, it's probably already too late to do that for Fusaka, and we also don't yet know exactly what we would need to make more expensive. What the immediate bottleneck is, unless, of course, if we today decide that we want, we are especially worried about state growth, we could make that more expensive, so that we can scale everything else. But it's just important to keep that in mind that, like on these things, we basically, we should try to be as forward-looking as possible, because hard folks have such a longer lead time than just client changes.

Tim Beiko: Right. And I guess this gets back to the original point of like, why do we want an eip that says, change the defaults in the Hard fork. I think to me this is kind of the main reason where there's a lot of work that needs to be done here, and if we don't have something in the hard fork that's saying we should work on all of the bottlenecks, then we will just do other things. I think we should also be fine with saying, like, if we have this eip that says, we increase the gas limit, and then we realize that increasing the cost of new state is the main bottleneck. We could add another eip to the hard fork that does this because it's like getting us towards that. But I I don't think it's realistic to say in advance, like, Oh, these are the 5 changes we're gonna wanna do that help us increase the gas limit, like, if we kind of like by definition, if we knew, we would have already done them. So like, yeah, the expectation would be that if we do have this, this

this eip in the fork. There might be other eips around pricing or around. Sorry, like other other parts of the clients that we we include through the like Fussaka development process that that help raise the gas limit. And it was already one of those on the agenda, for example, capping the Max, the Max block size, because there is a limit on the consensus layer. There's nothing really in terms of actual like storage, or like bandwidth size on the el. And so this is the thing we could do to like improve or I don't get us closer towards towards increasing the gas limit. but yeah, like, we, we could like do this because we've said, we want to increase the the guesstimate on l 1, basically

yeah, Ben.

Ben Adams: I just follow up on the block size limit on consensus layer. It's also a block size limit on Els in their gossip protocol.

Tim Beiko: Right correct. Can we come up with a way to vet that gas limit to state growth is linear proportional. It's reasonable. But it's an assumption. Actually, since 4 4, it's no longer proportional. I don't know. Storm is on the call. I think you're the one who's probably run the most analysis on this.

Storm Slivkoff: I have not actually investigated in detail whether it's linear, sublinear, super linear. I would expect it to be a little bit sublinear, but not totally sure.

Tim Beiko: Okay? and yeah, maybe if you want to post your your dashboards in the chat for people to review. But I think that's 1 of the the few things that we have in terms of hard data on this.

Justin Florentine: So just to clarify, I think. Excuse me if maybe testing in our shadow forking technologies could be explored in such a way that we could compress actual mainnet traffic into larger blocks with larger limits. I think that might be a little bit less of an assumption as to how that relationship works. I don't know that that's a thing. I don't know that that's possible, but it might be neat to explore.

Tim Beiko: Yep. And so yes, I guess maybe zooming out like I think the the Meta point is, there's a lot of work to do here to actually do this in a like intelligent way. There's a lot of different bottlenecks to consider doing. All this work is like takes away from obviously working on other eips for a hard fork, and therefore, if we want to prioritize it, we should like be explicit about this. We can't say like, oh, we're just gonna work on the gas limit on the side. Realistically, this means a year from now. We will not have done We will not have done anything or or that much. yeah, Micah.

Micah Zoltu: For generating test data. Could we maybe look at one of these other chains that has a ridiculously high gas limit and look at the types of transactions that people do on there just to get an idea of when gas prices are extremely low, presumably because gas limits are high. What are people using the chains for? Because the behavior patterns of usage may change significantly as the price declines. And so look at Suwana, look at base and see you know, what are people doing on those blockchains? Is it storage heavy, or is it compute heavy.

Tim Beiko: Yes, and I think, the get team has actually looked at binance chain a bunch in the past. But yes, we should compare with other chains. and again, yeah. like, there's a lot of stuff that we would need to look into to do this. Well, the question is, do we want to prioritize this over other things? And we should agree to that ideally today, because, yeah, if we just say there's a bunch of other stuff we're gonna work in. Then we are not gonna do all of this. yeah.

Micah Zoltu: Yeah, on that, I think the the thing that I think is might be useful or important is figure out what we think. The bottleneck is going to be like, what is the thing most likely to stop us from raising the gas limits and focus the research on that. As I mentioned previously. I feel like all the research is focused on validators and what they can handle. But if the bottleneck is Rpc. Providers, then it doesn't matter how great the how much you can crank it up for the validators, because your bottleneck's somewhere else so deciding and agreeing on where that bottleneck is, maybe, is the 1st step to reducing the scope of work that we need to do to figure out. Can we increase.

Tim Beiko: Yeah. yeah, I agree, we should basically figure out what all the bottlenecks are, and then kind of go through them one by one, as we raise the gas limit. Yeah. And that's again, that's kind of what the eip says. and maybe like, yeah. Another thing to surface. As we discussed this Dunkrat, you had a different proposal that we should that we should consider around instead of saying, like, we're gonna try our best and find a number you would you were proposing we should actually set a schedule and then use that as a forcing function. Do you want to maybe give some context on this.

Dankrad Feist: Okay. Yeah. I mean, I already wrote a little bit about the different factors. Motivating this on eth magicians, I think. For me. It's just the there are 2 things coming together, right like one is, I think if if we do want to do this like scale the l. 1. It only makes sense when there's actually some amount of reliability involved, like we'd need to tell applications developers where it is going to be in a few years like, if we just do this ad hoc, then maybe like they will decide now that well, I mean, sure, they're going to do a 1 time raise 250 million, and then we're back to how it was before, and that's all done. So

I think it's good to be more ambitious and actually enshrine some goals, I said. Why, I do think like something like 100 X is achievable. It's like a very gradual, exponential increase that's very manageable in the sense that, like for the 1st 2 years to 10 XI think we are very confident that, like all the problems are like at the very least known, and can be relatively quickly implemented. And and after that it becomes maybe more speculative. In terms of like how we can roll out zk, vms. that we can also start. We will very likely start within this year, and next year, so we will have plenty of data by then. But yeah, like to me, like.

it also involves a different kind of engineering. Like, if you know, you want to go to a hundred X, you make different decisions now than if you're like, Oh, yeah, like, we make some small improvements now. So I think to me it's just the better way in many ways to like, try to commit to something more ambitious. Now I don't think it's crazy. It's achievable, and and then plan backwards from there for the next 4 years. What research and implementation has to be done.

Tim Beiko: Okay, thanks. There are dumb comments in the chats about this. Yeah, anyone wants to share on the call.

Marius van der Wijden: I don't know this. Both of these proposals to me feel like we're trying to like. Everyone is trying to change something that everyone is trying to push for the air want to increase the gas limit, but they don't know where to start. And so the way they think is, or the only way that they can think of is to write an eap. From my point of view, it's just way too early to write any eap about this we should do the work to, or we're doing the work to, to figure out where the where the issues are, where the where the edge cases are where the worst cases are, so that we can safely increase the gas limit. It makes no sense to me that people are writing Eaps, especially

like people that are not really involved in in actually the investigation in the software.

Tim Beiko: Okay. And so you think we should just not have any IP and do the work. And that's it.

Marius van der Wijden: Yeah.

Tim Beiko: And I guess. And then do you think that there's like a resource allocation question? around like, okay. So if we have no eip for this, do we just say. you know, there's like nothing else, or very little, in Fusaka, and you know we kind of all work on the gas in it on the side. This is the part that just feels very weird, like, if this is actually something we want to do seriously, we should make it clear to ourselves in the community like this is the priority vips are like the tool we have for that. I'm if there's something else we can do. That's fine as well. But yeah, hey. yeah. Otherwise, like, I guess the risk is just we, we say, we're gonna do that. And then

other stuff just gets prioritized above it. Button, yeah. Lukash. Maybe.

Łukasz Rozmej: So yeah, this is an unusual eap, because it's not really technical. But it's a goal rather than improvement, right? So kind of way that doesn't specify how. But it specifies where we want to be. So it's different than the other. Ap, so in that way it doesn't really fit to Eaps, but based on the I think a bit of a joke in the chat team. You said to treat it as a Jira ticket. Then I'm fine with that. So I'm fine with having this first, st the IP as a like, the signal to the community that we are working on that actively, and this is one of our priorities. As for Dankrat, second dap, I'm more

reluctant to to to include something like that, because we don't know where we think the safe limit is. and I'm not convinced. Maybe we can. We can achieve these goals. But maybe we'll find a roadblock during that. And well. the point more. Maybe it's more than hype generation, or like conviction that we can achieve it or not. But I myself, I'm always under promise over delivered, and the other way around. So I like I don't feel comfortable to committing to something that I couldn't with. Let's say, minimal changes run now on at least my code. and I don't think I'm confident in that. We could run with such aggressive limits now, so

I'm not convinced for that. That one like it can be like a goal more even like a vague goal. But I wouldn't commit to it as a, as a, as a roadmap like that. We, we are confident in achieving that in this time scale.

Tim Beiko: Got it. Thanks. Yeah, I just want to address something like this is a weird eip. And Osgar had a comment in the chat like, should we be okay? Having small repricing eips in Fusaka. To me this is kind of the point of having this informational eip like, yes, this informational eip is kind of useless in a way like it doesn't propose any changes except eventually agreeing to a default. But the idea should be that if we have this, and then we work and prioritize improving the gas, and we realize that some repricing is the main bottleneck. We should be okay having your repricing that goes in in 3 months in the Fusaka Hard Fork. I I just don't think we can predict in advance today, like, Oh, here are like the 7 things we need to actually do to increase the gas limit. And there's kind of a chicken and egg problem here, where like, until we actually do the research and do the work and find what the bottlenecks are. We're not going to know what the repricing or other things we need to change are so

if we add the cip in, we should be okay saying other eips like. And specifically, protocol changes related to it that help us unlock a higher gas limit like may be added to Fusaka, even though we're like passive line But yeah, because we don't know what those vips are. Then we can't really add them today. and I, yeah. And maybe we can reflect this more explicitly in in the text. But yeah, that would be like a the thing we kind of commit to Yup.

Guillaume Ballet: Yeah, that's something that echoes a bit with, Marius was saying. But this is the second time I hear people saying in this call that we'll have next year. No, that's not happening, none of that work to to to assess, like the the work, to assess whether or not those big claims are holding water have barely started, and there's a lot of fine print coming with it. If what I mean is, if your way out for passing your eip is counting on zk vms being delivered next year, like we should not consider the eip at all, because there's so much uncertainty about those things when they will be available if they're going to work at all. I mean, of course, they're working. But if they're going to work for our specific use case. Yeah, for me. That's a big red flag.

Tim Beiko: Okay? yeah. So anyone else have other thoughts on this. Otherwise, I think you should make a decision about. do we want to prioritize either of those things for Fusaka. And then there was a comment earlier in the chat about other Cfi eips which I think should also agree to today. But yeah, this one kind of feels like the most consequential. So yeah, I think we should make that call first.st Okay, Lucas shares like some context on how gas increase is being tested to be safe. do you want to cover that? I know another mind has actually been doing some really cool work there. So

Łukasz Rozmej: So I'm not the main person working on that. So I not sure if you have Camille. But I see Martin in the chat. Maybe he wants to join in.

Marcin Sobczak: Bye, so hmm, what we can achieve here, is hmm. like, we have some test cases which can be optimized or potentially one or 2 repris. We can do one or 2 repricing to achieve like everything on ethereum being, at least as fast as easy, recover, compile. and going above it would be more challenging as like you see, recovery is a reference for for many other of codes and and precompiles so we can have some estimation how far we can go without like a bigger refactors in interior by simply checking on some reference machine how easy recovery is performing on all execution clients

and then, probably we need to to optimize some things like client specific things, and maybe some repricing. And we'll get there.

Łukasz Rozmej: So maybe if I can chime in. So never mind, team is like dedicated to to ensuring that gas limit increases are safe. So, for example. we are especially testing like edge cases for that, that if you fill the block with different edge cases, you still have reasonable block time on on, and we are testing it on all clients, and we have tooling for that. We build it over the years, and we will be. We'll be continuing on that. So we what we want to do is kind of at least from the execution standpoint we can discuss about the state growth and different things are another angle, right? Or or

snap sync, and Jason, Rpc, though I don't. I think Jason, Rpc. To be honest, currently at the least of our problems because it's horizontally scalable. But okay, but at least from the execution standpoint, the core protocol that yeah, that's the main thing. And up to some point, we, we think probably it will be relatively easy to scale, and then we probably hit some precompiles that could potentially be used to attack ethereum and causing potential issues. If you fail, block with those precompiled calls. But then we might at this point suggest some repricing. If we want to go above some gas limits for those precompiles. So that's that's it. So we will be trying to guard those a lot of those edge cases and advice on where the safe limits. Here and there.

Tim Beiko: Thanks. And then, yeah, there's a good comment from Justin in the chat as well that like, we should also solicit, like input, from the community in terms of tests and and things that they want. Yeah, to make sure, we we validate against which I expect we we should be able to do through this. Ben.

Ben Adams: Yeah. And I'm sympathetic to this gas defaults eip as going. From what you've recently written. as the defining feature of the of the 2 soccer folk on the El side. Even though it's more more like a visionary eip than a concrete implementation. It. It gives us a goal, whereas otherwise we don't have anything written down. As this is what we're targeting.

Tim Beiko: Right? And yeah, again, I realize it is like a a weird vip. But I think the thing that's come out of this conversation so far is just the amount of work that it will require to do this. Well. And so, yeah, we should ideally prioritize it. I feel like we've kind of covered all angles of this. So at this point it probably makes sense to just like hear from crime teams like, do you think we should sfi either of the the 2 gas limit the Ips. And then if there's other things in the Cfi list that people feel more strongly about yeah, we can also discuss those. But ideally making a decision around the gas limit being, the priority today would be good.

Marius van der Wijden: I think that kind of misrepresents the debate. Like we're not. We're not really making a decision about whether the gas limit is a priority. Right now we're making a decision whether this specific eap should be sfied, I think we should make gas limit increases a priority. Still, don't think we need an eip for that. But I, personally, not speaking for the guest team, I personally would be of yeah, neither against nor for sifying the cip. the the one. The one thing that I that I want to stress, though, is like, if we sfi this eip, it doesn't mean that we will increase the gas limit by the by, the Fusaka Fork. If this work turns out to need bigger refactors, bigger repricings that we cannot

move into the Fusaka fog, and we have to ship in a Glamsterdam. Then I would be against raising the gas limit for Fusaka.

Tim Beiko: Yeah, I think that's fair. I would personally consider that, like, you know. not ideal. But I think we should not delay peer to us on this. And so if if it turns out that there's literally 0 improvements we can do after spending months on it that can ship by Fusaka, we should not raise it. I'm but yeah, the ideally we we are able to find something. Yeah.

Marcin Sobczak: Yes, so for Fussaka we already proposed the repricing of modex precompile. And right now, like edge cases of modex precompile are like the the biggest bottleneck, and it's like twice slower than than the next one. So, having modex repricing in Fusaka will unblock potential gas limit, increases a lot, and all the others can be shipped later if we find found something else.

Tim Beiko: Andrew.

Andrew Ashikhmin: Yeah. So I think we should assify the the gas limit increase aip to just signal to the community that we are working on it. And it's it's in focus for Fusaka. And I would for Fusaka. I would cfi the less ambitious. 1, 79, 35, because the exponential one we can consider as a finance for for later hard forks. And this one is just very kind of vague. It's just basically says, says, the limit to XX, 0, m. Right? And basically that Xx can be can stay 36. If, like Marius concerns are valid. And we find out that basically we cannot do anything material in this timeframe. But I think it does send a signal that it is an important focus for us.

Tim Beiko: Thanks. Yeah. Justin.

Justin Florentine: Sort of agree here. I do definitely prefer 7,935 over the exponential one. I would like to see the backwards Compatibility section of that eip fleshed out and to include a little bit more rigor on what exactly we test for with regard to determining its safety bonus points for making that a reusable suite of tools that the community can go over vet contribute to. And I think eventually I'd love to get us to a world where we're either committed to networks and community operators really having more control over the gas limit safely. Right now, it's an ambiguous thing where we say, Yeah, anybody can adjust it, but nobody really should until we have determined that it's safe. So we're in kind of a split brain mode here, and I'd also like to see that. Resolved. I don't know if that's realistic to be in scope for this eip, but I think it's doable. So that's a long way of me saying, I think the debate around gas limit needs to be reframed, and we need to decide one way or another who's making that call.

Tim Beiko: Right. And I think yes. my biggest concern about the gas limit today is our approach to raising it is we do absolutely nothing. And then there's enough noise on Twitter that we realize like, oh, we should actually look into this. And then we kind of scramble together to like. do a bunch of analysis last minute. It would be a much healthier place if we always had a sense of like. These are all the bottlenecks. This is where we're working on. These are what we hope to unlock. And we can kind of suggest a gas limit. yeah.

Justin Florentine: Yeah. And I'd like to see a world where the community comes to us with that, with a lot of data and not just complaints, and I think that's doable.

Tim Beiko: Yes. Anyone from Ref on the call. Okay. So I guess if I have to recap now, it seems like various from Geth is likely against, but not too strongly opinionated. Never mind, Aragon based you seem on board with the 1st sip. So 7, 9, 3, 5 that has this vague goal? any other client teams have thoughts, or, you know, perspectives on this? Okay, I guess I would leave like, we have discussed this for the past. I think 3 calls at this point like I would lean towards estifying the

info eip. This is I again like a weird thing. So I think going with the less the like, more under specified one, for now is probably better than trying to commit to the more ambitious one proposed by Dancrat right out the box. yeah. If someone from Ref could plus one or raise an objection, that would be that'd be good. Okay, Roman said in the chat, they're supportive of including it. So okay. let's move forward. Then, with 7, 9, 3, 5, yeah, for Fussaka. And again, this this implies that there probably will be other vips that get added as we identify some bottlenecks. And then on that front, actually, there was already a 1st one for people to review. I don't think we should add any more about the gas limit today, but at least people should be aware of. Of this? One. 7, 9, 3, 4 by Julio Ben, and storm do either of you want to give a quick overview of the eip.

Ben Adams: I can depending, if Julia's on call.

Tim Beiko: Yeah, go for it.

Ben Adams: Okay? So in the Cl. There is a limit on the gossip of 10 MB. Also in the El Gossip is a 10 MB limit. So this is saying that blocks to recognize that and say that blocks cannot be larger than 10 MB minus like a safety margin for the Cl wrapper. Otherwise, if blocks are larger than that, you know they they can't be propagated. So you know, in in actuality they can't be larger than that, whereas if we commit to this, then we don't have to worry about like you know, what happens with call data getting too large or anything the blocks just will be invalid if they're too large. So it's just recognizing that as a side effect. This is a a question

we can actually control the bandwidth requirements if it was set lower. But that's that's an aside.

Tim Beiko: And then the question, yes, is this for Fusaka? Yes, potentially so. The idea is like this could be one of the things we include related to the gas limit Micah.

Micah Zoltu: Correct understanding. This is basically just being explicit about a requirement that we already have today.

Ben Adams: Yeah, that's correct. But if if blocks were larger than 10 MB uncompressed, it would just fail. But it's just saying, if you try and build a block larger than that market is invalid.

Micah Zoltu: Currently all clients have this problem. So it would be a a consensus. They would be in consensus if you somehow managed to get a 10 MB block in today, or would some of the clients succeed, some not maybe, fall out of consensus.

Ben Adams: It's specified in both the Ptp. And the consensus spec to drop any periods that try and send you that a block. Epic. Well, a message. Epic.

Justin Florentine: Wait. So you're saying that it's a propagation protection like it's being. It's being protected from Micah's concern at propagation time.

Ben Adams: Yeah, so it's enforced at the yeah, the network player. If you send a message that when it decompresses it's larger than 10 MB, you will be dropped as a pair. so therefore we cannot create blocks larger than 10 MB and have them part of consensus. So it's just recognizing that and saying, Well, if you try and build a block larger than that, it's an invalid block.

Tim Beiko: Alan.

Ahmad Bitar: Just to make things clear like the propagation protection is already in like currently Cls and Els do not propagate any blocks bigger than this. But previously we used to not have blocks bigger than this limit, because the gas limit is limited. Now, if we want to increase the gas limit. then we will hit that wall if we don't put another condition on built blocks, that they should not exceed this specific size when built. So this just adds, as I said, a condition, or like a constraint on the builder, to build a block not bigger than this, so when it finds that there is some transactions that have some really large amount of call data. For example.

it might drop these in favor of smaller, more paying transactions, just so that it does not exceed the block size, that is, that constraint. The constraint, yes, is already exists, but this makes it explicit for the builder to say, Hey, like, if your block is bigger than this, it won't be accepted, won't be part of consensus.

Ben Adams: Yeah, rather than I mean, potentially have a weird error condition. If somebody has a bug in hearing, and they don't actually reject it, then. without having a problem.

Ahmad Bitar: Yeah. Previously we had, like tested something with spolia, I think, where some clients had limits configured different than other clients. So some blocks became canonical for some clients and other clients didn't even see those blocks because of the propagation protection or something like that. My memory is fuzzy on this. So if someone who knows maybe can, can. yeah.

Tim Beiko: Okay? And yeah, I think even though this seems promising, we should give people a couple of weeks to review it. before we actually included and say, like the 1st Osaka devnets. But should we consider effectively like Cfi ing it for Fusaka? And then, yeah, potentially.

Ben Adams: I mean, follow up. Clarity on this is you can only achieve blocks this size by sending. Say, say, we're 110 mega gas blocks. You can only achieve a block this size by sending a single transaction that fills the block within zeros. So it's not like a productive block. It's just like an attack block. So it's saying, Well, that's that's not allow them to exist.

Tim Beiko: Got it. Anyone else have thoughts on eap.

Andrew Ashikhmin: Seems like a good one, and we should include it especially given that we want to increase the gas limit.

Tim Beiko: Okay, so it seems like, there's some desire to include it by the team. So I I would push for us to cfi it still have some time to review before we we decide whatever we want in the 1st devnet. So that's a 7, 9, 3, 8, and then the other thing. So for Fusaka we have all these Cfid Ips I posted in the chat we should determine what we want to move to our 1st Fusaka devnet. So what we want to actually, sfi I think a light client had eip 7, 9 0, 7 in the chat as one that he wanted. But yeah, curious to hear from client teams like, what do we think should be

specified for the 1st Fusaka devnet. So yes, pure desk is already sfi, do we want anything else? Because I believe we do have peered us def nets. So if if we don't feel okay. MoD. Xp repricing. Yeah. I guess, Maris, do you wanna make the case for audits? Be repricing or.

Marius van der Wijden: No, I think Netherman should make the case for it, because it's it's the eap.

Tim Beiko: Okay, so, and this is a 7, 8, 8, 3, right? Yeah. Okay. It seems like, Besu is up.

Ben Adams: Yeah, the the modex piece, because modex piece pricing is degenerate. It's it's not correctly priced compared to any other operation. So you can create. Prior to that blocks. Lucas.

Łukasz Rozmej: Yeah, exactly. Modex has edge cases that could allow for fairly long processing time. With 36 million limit. We are still, let's say, in in fine window here, but if we go not like 2, 60, or 100 etc. it will probably could could be seen as Worst case scenario should could be too too bad with the current pricing.

Marcin Sobczak: Yes, it's a big, because blocker with a big margin for potential increases in cost limit.

Łukasz Rozmej: And we do have some test cases that we were sharing in the past. I think we can share them again. But I will leave that to Martin with our core devs.

Tim Beiko: Okay, thanks. So okay, so it seems like, 7, 8, 2, 3 is pretty unanimously. oh, sorry. Okay. There's actually 2 monitors. Pep. So I wanna make sure which one I'm talking about is this, 7, 8, 2, 3. To set upper bounds, or 7, 8, 8, 3. The gas cost increase, or both.

Łukasz Rozmej: We are mostly focusing on 7, 8, 8, 3, but I think both can be viewed as as making contribution to to the goal.

Marcin Sobczak: Yes, 7, 8, 8, 3 are reprising like the the slowest scenarios, worst worst case scenarios, and the other one is setting that like upper bound for for size of of of call to modex. And it's limiting like such a big cases that were never never happened on on my, not like the the biggest size of of any parameter was 513, and it's setting up about on 1,024. So it's just eliminating potential future cases which which never happened.

Ben Adams: And I think there's been potential consensus issues with, they're all in the like, larger areas as well. So it sort of limits the the scope.

Tim Beiko: Okay. And Mario raised in the chat as well that none of the eips have proper tests for them yet, and ideally they should before Sfi. So I think, whatever we sfi, we should also be okay, or have someone who's like willing to break the test and and help move that forward in the next couple of weeks. So if we move forward with the 2 MoD. Xp eips, is there anyone who can commit to actually helping with the testing support for those dad, Mario.

Mario Vega: Yeah, it wasn't meant like to be like a a blocker, which is a reminder of the process that we said, we want tests before Sfi. And and it's not a problem we can. We can start the effort on on it. And we can update maybe on the following couple of weeks. The reason there there's no tests be right now is because of the switch of the Eof, no aof effort. So yeah. But basically, we can. We can implement them? Just it's gonna take a couple of weeks. May maybe.

Tim Beiko: Okay, and Lucas, you say there's a.

Łukasz Rozmej: Well, I'm not if they are implemented, but they are. There are like test cases with the previous previous price and new price in in the eap. 8, 7, 83 eap. So just changing a price. And and it's easy to get a test. But we we have, like test cases in mind at least.

Marcin Sobczak: Yes. So we had some potential vectors from the the last models for pricing. So it was too far. La! Last time when this this equation was changed, and I added 9 test cases which are slow, too. And I I already shared it on on many groups. So if anyone is interested, I can just share this this file again. It's like the test cases from from the last repricing plus new cases.

Tim Beiko: Okay. So I guess if we were to move with these 2 forward for Fusaka devnet one, do we feel confident, like we would be able to get sufficient desk coverage quickly enough, and.

Mario Vega: I think a same thing to do would be which ones of this service and the highest priority. And then we can focus on testing those. and then Cfi in those or.

Tim Beiko: Okay, sfying those. Okay? And I guess. yeah, Matt has a point like saying, like, we should maybe just agree on what we want. The Sfi here, and then make a final call in 2 weeks. Have the 1st definite with just pure das? I guess my question there would be like, don't. We already have pure das definites? And it's fine if we want to just have that. But yeah,

Lightclient (Matt Garnett): Yeah, I mean, what is the state of the periodic evidence for people? Is it based on Master.

Barnabas Busa: I think every single client is still in there. Custom branches. It's it's still highly work in progress.

Tim Beiko: Okay? So we could. I think it's it's also reasonable to say, Fusaka def net. One is just pure das, and then what we would want to aim for by next acde is the list of eips. We want to sfi and include in the 1st devnets and then try to get tests written for them. In in that period. Does that seem reasonable?

Lightclient (Matt Garnett): Yeah, I think I'm just trying to de-risk spending a week or 2 writing tests for something that clients aren't going to Sfi like. It's 1 thing to write the test and find that there are things that we didn't anticipate, and that's the reason why it doesn't get Sfi, or it doesn't go on a devnet, but like for 7, 9, 0 7, like, I can work on the tests. I just don't want to spend a week doing this. And then a client saying, Yeah, well, we didn't want to do this, anyways. So that's just a waste of everyone's time.

Tim Beiko: Agreed. So okay, so can we get maybe like A, I don't check from the clients of this of today like what they would want to move forward in a devnet, so never mind, posted their list in the chat. It was 7, 2, 1, 2, 7, 2, 8, 3, 7, 8, 8, 3 and then, I think, one of 7, 9, 17 and 7, 9, 18 or sorry. No, both 7, 9 17 and 7, 9, 18, and then, yeah. My client 7, 2, 1, 2, the 2 MoD xps and 7, 9 0, 7. Justin, I mean, I'm reading what's within in the chat.

Justin Florentine: Right. But amongst which teams I'm seeing a combination of eips from both Nethermind and Gath. And I'm not sure what overlaps and is okay? And that's all right. That's a personal list. Got it so like, what.

Tim Beiko: Okay. So I guess if teams haven't had time to review this, which seems to be the case, what is like the timeline on which we want to make this decision. Like, if we wait. do we want to wait the whole 2 week cycle to review the current Cfi vips and then make decisions. Do we want to just decide this next Monday? Is that enough time for people? I think it's hard to do Async, because, like, it's usually a bit more subtle than just team A wants these vips, and then team B wants these cips, and you just get like the intersection. But I think if, if yeah, by Monday the different teams could agree to which of the Cfi eips we should prioritize for Fusaka devnet 2, that would be ideal. We can have Fusaka devnet one be just pure das, and

yeah, I can make sure to update the list today. But basically the only addition we'd have in the list to what is already. There is 7, 9, 3, 8, this one about the 10 Meg the 10 Meg, Max, watch sites. But yeah, I think it's reasonable to just wait until Monday. If if people haven't had time to properly review this and then, once we know that on Monday we or I guess once we decide that on Monday we should take like the testing like the the cost of testing into consideration as well. So we should just like Sfi, the things we think we can reasonably test by the definite after the pure. That's only definite.

Does that make sense? Oh, yeah, sorry. I don't know why I said, the 7, 9, 3, 8, yeah, 7, 9, 3, 4 is the one I meant. With regards to the the cap on the block size. Yeah.

Lightclient (Matt Garnett): I mean, is there a reason that we can't just kind of decide what we want to target for the next? For the testing.

Tim Beiko: People just people seem very uncertain.

Lightclient (Matt Garnett): I mean, these eips have been cfi'd for a month.

Trent Van Epps: A month leading up to Pector.

Tim Beiko: Yeah, we've there's been a lot to do, and I do think it'll be like, I. I don't think that we lose much by taking a couple of days staff teams. Property. Yeah, property review this. And then Mario also says that by tomorrow they could share an overview of like what they expect the testing to be. And yeah, I don't know if people want to make the call for just MoD. Xp, like that. One feels like the one that has the most consensus consensus around. So we could say that definit one is just pure das, and these 2 MoD xp, Ips? I guess. Yeah, maybe. Is there a preference towards? So I guess, Daniel like, why would we, Cfi something not consider it the Sfi

we need to cap how much stuff we put in the next step that so like we should not realistically end up doing everything. That's Cfid. So we need to figure out like which of these are the highest priority? And which ones do we want to move forward with now? It's much harder to like implement 10 different things in parallel than it is to say, like, here are the 2 things we're working on right now. so that's what we're trying to get at.

Daniel Lehrner: Just just maybe one thing I'm I'm not really sure if it's the original goal to ship peers as soon as possible. You know if if it really fits. If now we consider. I don't know to to add a lot of other eips, or even to add any other eips. So I'm not. I'm not sure where people feel comfortable that they say this does not. Delay peer does, because I think every single eip potentially delays peer does that. We had.

Tim Beiko: I don't know that this is true, because we have a lot of work on the Cl. Side for pure das, and say something like repricing. MoD. Xp is pretty straightforward, so like, I don't expect that we're pricing MoD. Xp would be the thing that delays pure das, and there's probably a bunch of others like that. But I do think we need to like incrementally, add them to to the definites, because if we just add everything at once, then it becomes much harder to test. Yeah, Marston.

Marcin Sobczak: Yes, I I agree with team modex at least 7, 8, 8, 3. It's like a free license, free lines to be changed in client implementations, and if we don't do it, we will like block increases until the next car, for so we just need need to do it in the next one to to unblock gas limit increases.

Tim Beiko: And yeah, just I think we want to. Also, maybe, like, think of scope sizing there like we don't necessarily want to blindly. If everything in see if in, see if I had test tomorrow, I don't know that we would add them all into the second devnet. So we should balance like, okay, what's the amount of things we want to realistically implement the new devnets which ones are the highest priority and kind of iteratively go from there. I do think, like, I know, based on this conversation like it feels like there's a lot of uncertainty. Not a huge rush to make this decision. So I think it's worth waiting until Monday. it would be really helpful if, like, yeah, there is a doc from the testing team that kind of evaluates what's like the expected testing burden of of these different eips. We can use that in in the decision. And I think on Monday we can also make the call of around whether we actually want

whether we actually want the MoD Xp eips in the 1st peer desktop net or not? Yeah. I guess. Okay, point like, yes, we're talking about the ordering of when we bring them in. And I do think this is important, because if we bring everything at once, then it all gets coupled, and it becomes much messier to remove and undo. So we should be like judicious in what we choose to bring, and when and then it's possible that we don't get through the entire list because there's just other stuff, or because we're ready to ship pure Nas, or because something a little more complex than we expected. Okay, so yeah, to recap, I think let's make this call on Monday. So client teams should review what's in the Cfi list including this new 1, 7, 9, 3, 4 about the the limit on the block size.

And then we can decide what we actually want in definite one, along with pure das, if anything. And if we want to wait beyond that, or if we're on definite one to just be pure. Das, that's fine, too. But we can still prioritize the ordering. Yeah. And I think, anyways, I think what I could also do on Mondays right now the the list is sorted by eip number, but we could also just like sort it by priority or something at some point. So that it's it's a bit clearer going forward like, what's the order in which we pick from to include stuff button? Yeah, I actually, maybe, yeah, this is okay. To make it even more concrete. I think this is probably like the most helpful thing is like

getting an ordered list from every client team of the stuff in Cfi. And in what order would you prioritize? Pulling it into Fusaka is probably the most helpful data point, and we can use that to make our decisions. and then yes, we can kind of merge these ordered lists on Monday and determine which subset. We want to include right now. Does that make sense sorry? I know this was confusing. But I think we have a clear next step. Okay, perfect. So like. Yes. Again, the list that's there, plus 7, 9, 3, 4 is what we are trying to sort before Monday. okay. So I think this covers the Fusaka stuff. There was. So Greg had a comment following the Eof removal around, whether we would ever get the removal of dynamic jumps in the Evm. We only have 10 min here. I don't think it's like the right time to make a decision on this, but I don't know what is the right forum that people feel we should use to discuss this and what the path forward for the Evm should be.

does anyone have a suggestion here where.

Greg Colvin: It's just important, because we've been at it for 10 years. And it's it is the key to unlock almost any progress in any area of the Vm.

Tim Beiko: Marius.

Marius van der Wijden: Yes. So I think we should do this on Acd, especially when we're once we're moving to this new model of discussing like higher level ideas on acd acde, and then discussing the more current stuff on scd tea. So I think this this would be the right venue for it. I can also give my opinion on it right now. I don't see removal of static jumps a priority. I just I don't. I don't see the the use cases that it it unlocks. I know there are some, but I don't see this as a priority over other things that we could prioritize.

Greg Colvin: Every formal analyst and auditor I have talked to for 10 years have told me. Please get rid of this. It is in the way totally in the way all of the research I want to do I cannot do, because it's in the way any attempt.

Tim Beiko: Like. But okay, just to like.

Greg Colvin: We went from.

Tim Beiko: Full of.

Greg Colvin: The goddamn thing is broken.

Tim Beiko: Sure. But there are many things that are broken with ethereum. There's a lot of things we need to do. So I guess Tamaris's point is like, yes, it's like a relative prioritization thing. If we had infinite resources in infinite time, we would do all the things.

Greg Colvin: We're not going fucking. Do this, I will go away and quit bothering you.

Tim Beiko: Like. I guess I do think the way to address this would be either. Yes, there needs to be like a longer term effort around the Vm. Or if there's a specific proposal for the next fork, like we should consider it, and you know. weight it against the different like relative prioritizations. But yeah.

Marius van der Wijden: So from my point of view, we've we have considered it many times. I have considered it many times myself. I don't think ethereum is broken. Yes, I.

Greg Colvin: As this program.

Marius van der Wijden: As as as Tim said I, I would like to have this. I think it's a it's a nice feature to have only static jumps. I also I see the problem with the dynamic jumps. I dislike the jump, desk analysis, and all of this. but I don't see this as a priority over other features.

Greg Colvin: The main thing is a forum, because we won't resolve it. Now.

Tim Beiko: Yeah. But so I guess. And yeah, this is like skipping ahead Forum and a commitment.

Greg Colvin: A commitment to either do this or not, because if we're not going to do it literally, I I should go away. I'm wasting my time.

Tim Beiko: Right? Okay, so this is skipping ahead a bit. But yes, I think it's fair. That's like, yeah, we try to give commitments. There's 2 challenges there. One is. I don't think all core devs can actually commit to anything beyond like the next fork in the future. we've tried this in the past, and it's horrible, because we then have priority shift, and the people who thought they had their thing committed to are even more disappointed than if we had not made any commitments at all. That said a lot of the stuff that we need to do takes more than one hard fork to develop and implement and whatnot. We have had a bunch of working groups and breakouts to do this. And

we I think the the mistake we've made there is that we haven't had like a way for these breakouts to like. I don't check in with all core devs about is their thing still a priority, and should they keep investing time on it, this is something I would like us to start doing and ideally, we can catch things, you know, that become less of a priority earlier in the pro, in in the, in, in the in the process. But but but yes, like I. I don't think we can give you an assurance like this will never happen. We keep all Cornez can give you an assurance like whether or not. This will happen in the next fork. If we want to start an Evm working group, I think we should be better at

every fork, at least looking at every existing working group, then assessing like, does this thing still make sense or not? But yeah, I I just don't think it's possible to give you a commitment that's like better or stronger than that. And then, you know, based on that, obviously, you should make a call of whether it's worth it to invest your time on on these efforts. But I I like, Yeah, I I'm very weary of just giving people the impression of.

Greg Colvin: When they're just there, isn't it just took years of work by a lot of people and shit candid to the last minute. Why should people put in this kind of work.

Tim Beiko: Correct. And look I I mean. I think the signal like Marius shared. And is that like, yeah, right now, this is not a priority. I think the signal from Eof was like this is also not a priority. Now. again, like no one can stop you from putting in the work, but I I think if you want, like an explicit like thumbs up from all core devs, the best we can do is whether we want to consider this in the next hard fork. And you know you're free to make a proposal for.

Greg Colvin: For that system.

Tim Beiko: But yeah.

Greg Colvin: The work. The work is ready to go in.

Tim Beiko: Yeah. So okay, so then, when we start planning Amsterdam, then I think we should have a Clamsterdam proposal about this. But yeah, we only have 3 min. So I do want to move us forward. But to answer your original question, I think either we should start and working group around the Evm. And if it's already done, then I think we should have a standardized process to consider different things for hard forks, and this can be one of them. Yeah. but yeah, I do want to make sure we cover. There was a point around state growth metrics. So I'm I forget who put this on the agenda. But it's 1 of the important topics we discussed earlier. Cpres.

And yeah.

CPerezz: So together with never mind, and following what they did with Perfnet, and seeing that there's a great initiatives to bump up the gas limits. One of the things that we wanted to make sure is that we we can at least know which will be the consequences on state growth. Maybe not for the short term, but certainly for the medium term. So in regards of that, the idea was to start creating some kind of testnet where we can actually have gas limits from I don't know between 60 million 300 million gas per block and just bloat the test net as much as possible and see what breaks and what useful data can we get? So in regards the second one,

I wanted to make some Co, some kind of call to participation, or whatever, because there's a bunch of data that you can just retrieve from traces and blocks. But there's a lot of other data. That is just the female. So I don't know RAM metrics catch a misses or stuff like that, which, if you don't get it at the time. We will never get that information so I wanted to share the 2 links and invite everyone to collaborate or give any initiatives or any data points that they would be interested on having. Because we're doing this for sure, with the collaboration of Nethermind and any funds. And it will be really nice if we can get worse test cases, things that people want to trample with, like mess up with caches and see how this affects the performance on I/O, especially on breeds. And this kind of stuff, especially when we have terabytes of state, which is the the goal here. So yeah, just wanted to

to briefly mention it and and ask anyone to to help and collaborate if they want.

Tim Beiko: Thank you. Where's the best place for people to to follow up.

CPerezz: So at this time I would say, the gas limit. Testing discord channel is the place probably we will be creating something new or separate, so that we don't blow down the channel for things that are not completely related. But this should be the 1st place, and aside from that you can. Just DM, probably Camille, or anyone in stateless consensus and we will be happy to to help.

Tim Beiko: Awesome. Thanks. And okay, we're at time. And there was a bunch more announcements. So I'll just like run through them. And people can review those Async. But basically, I, I wrote a post published yesterday on on, like what I think the next step should be to implement kind of the process we discussed for all core devs. We briefly discussed it already. Someone also wrote a post about building some tooling for this so it would be good to review those before the next acde, so we can have like an informed conversation about it. There was also an eip where the author was asking for some feedback from guests, I believe in the agenda, so I'll post it here

and then, aside from this, there's 3 more things. Anskar. Do you want to give a quick shout out to the research call and then trend Petra pages, and if anyone can give an history expiry update, we can wrap up with that.

Ansgar Dietrichs: Yeah, sure. Thanks. There's the second summit of the research calls that we recently started. That will be next Wednesday at ether clock, and this time the topic will be especially relevant for people here, because it will be about the short term El scaling features. So not just the gas scaling, but the actual features that would improve that with the focus on the Glam Saddam feature set, but also a little bit beyond that we're still assembling the agenda once that I have, that I'll put that into the Acd channel as well for people, and I'll also reach out to some of you all to ask if maybe you'd be available for like a 5 min presentation on specific subtopics. So yeah, seeing many of you all there next week would be really good.

Tim Beiko: Thank you. Do, Trent.

Trent Van Epps: Sure I've DM'd. I think most of the people on this call with a final reminder for submissions. But a pector pages is a individual perspective on the the last network upgrade to complement the team perspective. So we've got about 40 responses right now. But there's 80 people on this call, and you know, couple of 100 people that were involved in Pector in some ways, and we'd love to feature what you think about it any nasty bugs you uncovered something you're particularly proud of, or like. a way for you to shout out people you thought went above and beyond. So check your DM. Or just reach out to me directly if I miss you in my reach out this week, or Nixo may have DM'd you? So we're we're planning to publish early next week. So this is the final call for submission. So if you're interested, please do reach out and fill it out, it's only about 1015 min to do. Thanks.

Tim Beiko: Thank you. Anyone on the history expiry side. Okay, and then, yeah, I'll reiterate the last action item. So before Acd on Monday. Client teams. Just look at the Cfi list. Try to sort it by priority. And yeah, we're already over time. We should discuss history expiry as well. But I don't think this call is the right. Yeah, the the right time left to do it. yeah, thanks. Everyone. And again, congrats on shipping. Petra. Yeah, it's live. It's still working. No one's paid me during this call to tell me there was a consensus bug. So yeah. great work, everyone, and talk to you all soon.

Alex Stokes: Thank you. Bye.

Łukasz Rozmej: Bye.

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