AllCoreDevs - Execution #211

|2025-05-08| Agenda: #1500| canonical JSON

Transcript

Tim Beiko:Thank you.

Tim Beiko:Welcome everyone to Acde at number 211. Lots of people added stuff on the agenda in the last few hours. So

Tim Beiko: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

Tim Beiko: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

Tim Beiko:and if we have time, after all that there is also another eip that someone wanted feedback on

Tim Beiko: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.

Tim Beiko:yeah, from what I could tell, it went pretty clean.

Tim Beiko:Okay, well, yes. Guess we can leave it at that.

Tim Beiko:again. Yeah. Congrats everyone on getting this shipped. It was a lot of work. And yeah, it is live.

Tim Beiko: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

Tim Beiko: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

Tim Beiko:sanity check that. There were no issues on my net.

Tim Beiko:so yeah, new thing we've done when testing this fork.

Tim Beiko:and yes, we could also pick it up today if people feel like.

Tim Beiko:But yeah, okay, moving on to Fusaka. So

Tim Beiko: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.

Tim Beiko: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?

Tim Beiko: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

Tim Beiko:on the El side. So

Tim Beiko:what we spoke about the last

Tim Beiko: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

Tim Beiko: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

Tim Beiko: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

Tim Beiko: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.

Tim Beiko: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.

Tim Beiko:yeah. Wanted to give people like a last chance to comment.

Tim Beiko: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

Tim Beiko:ish millions and it's hard to know but like, and the eip has like a

Tim Beiko:you know, 3 figure 1 million placeholder. But yeah.

Tim Beiko: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.

Micah Zoltu: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.

Micah Zoltu: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

Micah Zoltu: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

Micah Zoltu: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

Ansgar Dietrichs: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

Ansgar Dietrichs: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,

Tim Beiko: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

Micah Zoltu: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

Micah Zoltu:right that yeah.

Micah Zoltu: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

Tim Beiko: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

Tim Beiko: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

Tim Beiko:a tractable thing. So I I would separate those things, though, and I don't think that we're like anywhere near the

Tim Beiko:performance. Bottlenecks of, you know, infra not being able to serve Rpc access. But like, yes, this, the disk size is a concern.

Tim Beiko:I think Marius was next.

MariusVanDerWijden: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

MariusVanDerWijden:solved. Right now, we're status

MariusVanDerWijden:roughly growing by 5 GB a month, and so going to 60,

MariusVanDerWijden:a million gas will grow the State by 10 GB a month, which is 120 GB a year.

MariusVanDerWijden:Yes, there are other chains that are

MariusVanDerWijden: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.

MariusVanDerWijden: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.

MariusVanDerWijden:And so

MariusVanDerWijden:yeah, we should be. We should. Only I think we should only really increase the gas limit. Once we have

MariusVanDerWijden:a way of once, we once we also decide to increase the cost of storing stuff. Which

MariusVanDerWijden:in turn would make would make execution cheaper.

MariusVanDerWijden:and and and storing more expensive.

MariusVanDerWijden: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

MariusVanDerWijden: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.

MariusVanDerWijden:or it's not a problem.

MariusVanDerWijden:Yes, it's true, but size wise. It's not a problem.

MariusVanDerWijden:And the problem is that random accesses in this in this data will get much worse.

MariusVanDerWijden:So

MariusVanDerWijden: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.

MariusVanDerWijden:It's kind of where we where we kind of hit the wall where state access get extremely slow.

MariusVanDerWijden: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

Dankrad Feist:the reality is like, I think it's just time to look at what's actually happening, and that is that

Dankrad Feist:the number of ethereum users who run their own nodes and like use it directly through that

Dankrad Feist:is already extremely low, and like continuing to double down on a strategy that hasn't worked in the past is just.

Dankrad Feist:I think it just doesn't make sense to me like, I think, like our our real

Dankrad Feist: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

Dankrad Feist:like retrieving the State trustlessly for that. And

Dankrad Feist: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

Sophia Gold: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

Sophia Gold:medium term, stateless plan.

Sophia Gold: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,

Sophia Gold: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.

Tim Beiko:extremely expensive, but then accessing the existing state constant and grow the state?

Tim Beiko:Is it a problem is like more access across a smaller state within a given block size as problematic.

Tim Beiko:Yeah, I don't know if anyone has an intuition for that.

Tim Beiko:If not, this feels like something practical. We should test like, yeah.

Tim Beiko:How's it going.

Ansgar Dietrichs:Yeah, then, maybe on that point, just very briefly, like, I think we

Ansgar Dietrichs:as we start scaling the gas limit. Probably we should

Ansgar Dietrichs: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.

Ansgar Dietrichs: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.

Ansgar Dietrichs: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

Ansgar Dietrichs: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

Tim Beiko: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.

Tim Beiko: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

Tim Beiko:this eip in the fork. There might be other eips around pricing or around.

Tim Beiko: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

Tim Beiko:improve or I don't get us closer towards towards increasing the gas limit.

Tim Beiko:but yeah, like, we, we could like do this because we've said, we want to increase the the guesstimate on l 1, basically

Tim Beiko:yeah, Ben.

Ben Adams:I just follow up on the

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

Tim Beiko:Right correct.

Tim Beiko: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

Tim Beiko: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?

Tim Beiko: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 (Besu):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.

Tim Beiko:And so yes, I guess maybe zooming out like I think the

Tim Beiko: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

Tim Beiko: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.

Tim Beiko: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.

Micah Zoltu: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.

Tim Beiko:and again, yeah.

Tim Beiko: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,

Tim Beiko: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.

Tim Beiko: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.

Micah Zoltu: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

Micah Zoltu: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.

Tim Beiko: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.

Tim Beiko:And that's again, that's kind of what the eip says.

Tim Beiko:and

Tim Beiko:maybe like, yeah. Another thing to surface. As we discussed this Dunkrat, you had a different proposal that we should

Tim Beiko:that we should consider around instead of saying, like, we're gonna try our best and find a number you would

Tim Beiko: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.

Dankrad Feist:Yeah. I mean, I already wrote a little bit about the different

Dankrad Feist:factors. Motivating this on eth magicians, I think. For me. It's just the

Dankrad Feist: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

Dankrad Feist:some amount of reliability involved, like we'd need to tell

Dankrad Feist: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

Dankrad Feist: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

Dankrad Feist: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

Dankrad Feist:all the problems are like

Dankrad Feist:at the very least known, and can be relatively quickly implemented. And

Dankrad Feist:and after that it becomes maybe more speculative. In terms of like how we can roll out zk, vms.

Dankrad Feist: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.

Dankrad Feist: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

Dankrad Feist: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

Tim Beiko:comments in the chats about this. Yeah, anyone wants to share on the call.

MariusVanDerWijden:I don't know this. Both of these proposals to me feel like

MariusVanDerWijden:we're trying to like. Everyone is trying to change something that everyone is trying to push

MariusVanDerWijden: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.

MariusVanDerWijden: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

MariusVanDerWijden: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

MariusVanDerWijden: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.

MariusVanDerWijden:Yeah.

Tim Beiko:And I guess. And then do you think that there's like a resource allocation question?

Tim Beiko:around like, okay. So if we have no eip for this, do we just say.

Tim Beiko:you know, there's like nothing else, or very little, in Fusaka, and

Tim Beiko: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

Tim Beiko:yeah, hey.

Tim Beiko:yeah. Otherwise, like, I guess the risk is just we, we say, we're gonna do that. And then

Tim Beiko:other stuff just gets prioritized above it.

Tim Beiko:Button, yeah. Lukash. Maybe.

Łukasz Rozmej:So

Łukasz Rozmej: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

Łukasz Rozmej:I'm fine with that.

Łukasz Rozmej:So I'm fine with having this first, st the IP as a like, the signal to the community that we are

Łukasz Rozmej:working on that actively, and this is one of our priorities. As for Dankrat, second dap, I'm more

Łukasz Rozmej:reluctant to to to include something like that, because

Łukasz Rozmej:we don't know where we think the safe limit is.

Łukasz Rozmej:and I'm not convinced. Maybe we can. We can achieve these goals. But maybe we'll find a roadblock during that. And

Łukasz Rozmej:well.

Łukasz Rozmej:the point more. Maybe it's more than hype generation, or like conviction that we can achieve it or not.

Łukasz Rozmej: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

Łukasz Rozmej:I couldn't with. Let's say, minimal changes run now on at least my code.

Łukasz Rozmej:and I don't think I'm confident in that. We could run with such aggressive limits now, so

Łukasz Rozmej: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

Łukasz Rozmej:that. We, we are confident in achieving that in this time scale.

Tim Beiko:Got it. Thanks.

Tim Beiko: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.

Tim Beiko: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.

Tim Beiko: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

Tim Beiko:if we add the cip in, we should be okay saying

Tim Beiko: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

Tim Beiko:But yeah, because we don't know what those vips are. Then we can't really add them today.

Tim Beiko: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

Tim Beiko:Yup.

Guillaume: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.

Guillaume: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?

Tim Beiko:yeah. So anyone else have other thoughts on this. Otherwise, I think you should make a decision about.

Tim Beiko: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

Tim Beiko:yeah, this one kind of feels like the most consequential. So yeah, I think we should

Tim Beiko:make that call first.st

Tim Beiko:Okay, Lucas shares like some context on how gas increase is being tested to be safe.

Tim Beiko: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.

Marcin Sobczak: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.

Marcin Sobczak: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

Marcin Sobczak: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

Marcin Sobczak: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

Łukasz Rozmej:ensuring that gas limit increases are safe.

Łukasz Rozmej:So, for example.

Łukasz Rozmej: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.

Łukasz Rozmej:So we what we want to do is kind of at least from the execution standpoint

Łukasz Rozmej:we can discuss about the state growth and different things are another angle, right? Or or

Łukasz Rozmej: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

Łukasz Rozmej:yeah, that's the main thing. And up to some point, we, we think probably it will be relatively easy to scale, and

Łukasz Rozmej: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

Łukasz Rozmej: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.

Tim Beiko:Ben.

Ben Adams:Yeah. And I'm sympathetic to this gas defaults eip as going. From what you've recently written.

Ben Adams:as the defining feature of the of the 2 soccer folk on the El side.

Ben Adams:Even though it's more more like a visionary eip than a concrete implementation.

Ben Adams: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,

Tim Beiko:yeah, we should ideally prioritize it.

Tim Beiko: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

Tim Beiko:sfi

Tim Beiko: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

Tim Beiko:yeah, we can also discuss those. But

Tim Beiko:ideally making a decision around the gas limit being, the priority today would be good.

MariusVanDerWijden: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

MariusVanDerWijden:this specific eap should be sfied, I think we should make gas limit increases a priority.

MariusVanDerWijden:Still, don't think we need an eip for that.

MariusVanDerWijden:But I, personally, not speaking for the guest team, I personally would be of

MariusVanDerWijden:yeah, neither against nor for sifying the cip.

MariusVanDerWijden: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.

MariusVanDerWijden:If this work turns out to need bigger refactors, bigger repricings that we cannot

MariusVanDerWijden: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.

Tim Beiko:not ideal. But I think we should not delay peer to us

Tim Beiko: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.

Tim Beiko:I'm but yeah, the ideally we we are able to find something.

Tim Beiko: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

Marcin Sobczak: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

Andrew Ashikhmin: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

Andrew Ashikhmin: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.

Tim Beiko:Yeah. Justin.

Justin Florentine (Besu):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

Justin Florentine (Besu):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

Justin Florentine (Besu):safely.

Justin Florentine (Besu):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.

Tim Beiko: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.

Tim Beiko: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.

Tim Beiko:yeah.

Justin Florentine (Besu):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.

Tim Beiko:Anyone from Ref on the call.

Tim Beiko:Okay. So I guess if I have to recap now, it seems like various from Geth is

Tim Beiko: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?

Tim Beiko:any other client teams have thoughts, or, you know, perspectives on this?

Tim Beiko: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

Tim Beiko:info eip.

Tim Beiko: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.

Tim Beiko:yeah. If someone from Ref could

Tim Beiko:plus one or raise an objection, that would be that'd be good.

Tim Beiko:Okay, Roman said in the chat, they're supportive of including it. So okay.

Tim Beiko:let's move forward. Then, with 7, 9, 3, 5,

Tim Beiko:yeah, for Fussaka. And again, this this implies that there probably will be other vips that get added as we identify some bottlenecks.

Tim Beiko: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.

Ben Adams:There is a limit on the gossip

Ben Adams:of 10 MB. Also in the El

Ben Adams:Gossip is a 10 MB limit.

Ben Adams:So this is saying that blocks

Ben Adams:to recognize that and say that blocks cannot be larger than 10 MB minus

Ben Adams:like a safety margin for the Cl wrapper.

Ben Adams:Otherwise, if blocks are larger than that, you know they they can't be propagated.

Ben Adams:So you know, in

Ben Adams:in actuality they can't be larger than that, whereas if we commit to this, then we don't have to worry about like

Ben Adams:you know, what happens with call data getting too large or anything the blocks just will be invalid if they're too large.

Ben Adams:So it's just recognizing that as a side effect. This is a a question

Ben Adams:we can actually control the bandwidth requirements if it was set lower.

Ben Adams: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

Tim Beiko:we include related to the gas limit

Tim Beiko: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.

Micah Zoltu: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 (Besu):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

Ben Adams: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.

Ben Adams:so therefore we cannot create blocks larger than 10 MB and have them part of consensus.

Ben Adams: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 | Nethermind:Just to make things clear like the propagation protection is already in like

Ahmad Bitar | Nethermind:currently Cls and Els do not propagate any blocks bigger than this.

Ahmad Bitar | Nethermind: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.

Ahmad Bitar | Nethermind: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.

Ahmad Bitar | Nethermind: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.

Ben Adams:without having a problem.

Ahmad Bitar | Nethermind:Yeah. Previously we had, like tested something with spolia, I think, where some clients had limits

Ahmad Bitar | Nethermind: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.

Ahmad Bitar | Nethermind:yeah.

Tim Beiko:Okay? And yeah, I think even though this seems promising, we should give people a couple of weeks to review it.

Tim Beiko:before we actually included and say, like the 1st Osaka devnets. But should we consider

Tim Beiko: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.

Ben Adams:So it's not like a productive block.

Ben Adams: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.

Tim Beiko: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.

Tim Beiko:So that's a 7, 9, 3, 8, and then

Tim Beiko: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

Tim Beiko: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

Tim Beiko:specified for the 1st Fusaka devnet.

Tim Beiko:So yes, pure desk is already sfi, do we want anything else?

Tim Beiko:Because I believe we do have peered us def nets.

Tim Beiko:So if if we don't feel okay. MoD. Xp repricing.

Tim Beiko:Yeah. I guess, Maris, do you wanna make the case for audits? Be repricing or.

MariusVanDerWijden: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?

Tim Beiko:Yeah. Okay. It seems like, Besu is up.

Ben Adams:Yeah, the the modex piece, because modex piece pricing is degenerate.

Ben Adams:It's it's not correctly priced compared to any other operation.

Ben Adams:So you can create.

Ben Adams:Prior to that blocks. Lucas.

Łukasz Rozmej:Yeah, exactly. Modex has edge cases that

Łukasz Rozmej: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

Łukasz Rozmej:not like 2, 60, or 100 etc.

Łukasz Rozmej:it will probably could could be seen as

Łukasz Rozmej: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.

Łukasz Rozmej: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.

Tim Beiko: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

Łukasz Rozmej: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

Marcin Sobczak: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

Marcin Sobczak: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

Ben Adams: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

Tim Beiko:ideally they should before Sfi. So I think, whatever we sfi, we should also be

Tim Beiko: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

Tim Beiko: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.

Mario Vega: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

Łukasz Rozmej: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

Łukasz Rozmej:just changing a price. And

Łukasz Rozmej: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

Marcin Sobczak: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

Tim Beiko:I guess if we were to move with these 2 forward for Fusaka devnet one, do we feel confident, like

Tim Beiko: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.

Mario Vega:and then Cfi in those or.

Tim Beiko:Okay, sfying those. Okay? And I guess.

Tim Beiko: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

Tim Beiko:it's fine if we want to just have that. But yeah,

lightclient:Yeah, I mean, what is the state of the periodic evidence for people?

lightclient:Is it based on Master.

Barnabas:I think every single client is still in there.

Barnabas:Custom branches.

Barnabas: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

Tim Beiko:the list of eips. We want to sfi

Tim Beiko:and include in the 1st devnets and then try to get tests written for them. In in that period. Does that seem reasonable?

lightclient: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

Tim Beiko: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

Tim Beiko:17 and 7, 9, 18,

Tim Beiko:and then, yeah. My client

Tim Beiko:7, 2, 1, 2, the 2 MoD xps and 7, 9 0, 7.

Tim Beiko:Justin, I mean, I'm reading what's within in the chat.

Justin Florentine (Besu):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

Justin Florentine (Besu):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,

Tim Beiko:what is like the timeline on which we want to make this decision. Like, if we wait.

Tim Beiko:do we want to wait the whole 2 week cycle to review the current Cfi vips

Tim Beiko:and then make decisions. Do we want to just decide this next Monday? Is that enough time for people?

Tim Beiko:I think it's hard to do Async, because, like, it's usually a bit more subtle than just

Tim Beiko:team A wants these vips, and then team B wants these cips, and you just get like the intersection.

Tim Beiko:But I think if, if yeah, by Monday

Tim Beiko: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

Tim Beiko: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,

Tim Beiko:Max, watch sites.

Tim Beiko:But

Tim Beiko: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

Tim Beiko:like the the cost of testing into consideration as well. So we should just like

Tim Beiko:Sfi, the things we think we can reasonably test by the definite after the pure. That's only definite.

Tim Beiko:Does that make sense?

Tim Beiko: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: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:I mean, these eips have been cfi'd for a month.

Trent:A month leading up to Pector.

Tim Beiko:Yeah, we've there's been a lot to do, and

Tim Beiko:I do think it'll be like, I. I don't think that we lose much by taking a couple of days

Tim Beiko: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.

Tim Beiko: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?

Tim Beiko:I guess. Yeah, maybe. Is there a preference towards?

Tim Beiko:So I guess, Daniel like, why would we, Cfi something not consider it the Sfi

Tim Beiko: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.

Tim Beiko:so that's what we're trying to get at.

Daniel Lehrner (Besu):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.

Daniel Lehrner (Besu):I don't know to to add a lot of other eips, or even to add any other eips.

Daniel Lehrner (Besu):So I'm not. I'm not sure where people feel comfortable that they say this does not.

Daniel Lehrner (Besu):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

Tim Beiko:pretty straightforward, so like, I don't expect that we're pricing MoD. Xp would be the thing that

Tim Beiko:delays pure das, and there's probably a bunch of others like that. But I do think we need to like incrementally, add them

Tim Beiko:to to the definites, because if we just add everything at once, then it becomes much harder to test.

Tim Beiko: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.

Tim Beiko: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.

Tim Beiko: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.

Tim Beiko: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

Tim Beiko:whether we actually want the MoD Xp eips in the 1st peer desktop net or not? Yeah.

Tim Beiko: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

Tim Beiko:what we choose to bring, and when and then

Tim Beiko: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.

Tim Beiko: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.

Tim Beiko: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.

Tim Beiko: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

Tim Beiko:to include stuff button?

Tim Beiko: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

Tim Beiko:getting an ordered list from every client team of the stuff in Cfi. And

Tim Beiko: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.

Tim Beiko:and then yes, we can kind of merge these ordered lists on Monday and determine which subset. We want to include right now.

Tim Beiko:Does that make sense sorry? I know this was confusing. But I think

Tim Beiko:we have a clear next step.

Tim Beiko: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.

Tim Beiko:okay. So I think this covers the Fusaka stuff.

Tim Beiko: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.

Tim Beiko:does anyone have a suggestion here where.

Greg:It's just important, because we've been at it for 10 years.

Greg:And it's it is the key to unlock

Greg:almost any progress in any area of the Vm.

Tim Beiko:Marius.

MariusVanDerWijden:Yes. So I think we should do this on Acd, especially when we're once we're moving to this

MariusVanDerWijden:new model of discussing like higher level ideas on acd acde, and then discussing the more

MariusVanDerWijden:current stuff on scd tea. So I think this this would be the right venue for it.

MariusVanDerWijden:I can also give my opinion on it right now.

MariusVanDerWijden:I don't see removal of static jumps a priority.

MariusVanDerWijden:I just I don't.

MariusVanDerWijden: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: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:We went from.

Tim Beiko:Full of.

Greg:The goddamn thing is broken.

Tim Beiko:Sure. But

Tim Beiko:there are many things that are broken with ethereum. There's a lot of things we need to do. So

Tim Beiko: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: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

Tim Beiko:either. Yes, there needs to be like a longer term effort around

Tim Beiko:the Vm. Or if there's a specific proposal for the next fork, like we should consider it, and you know.

Tim Beiko:weight it against the different like relative prioritizations. But yeah.

MariusVanDerWijden: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.

MariusVanDerWijden:Yes, I.

Greg:As this program.

MariusVanDerWijden:As as as Tim said I, I would like to have this.

MariusVanDerWijden:I think it's a it's a nice feature to have only static jumps.

MariusVanDerWijden:I also I see the problem with the dynamic jumps. I dislike the jump, desk analysis, and all of this.

MariusVanDerWijden:but I don't see this as a priority over other features.

Greg: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: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.

Tim Beiko: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.

Tim Beiko:we've tried this in the past, and it's horrible, because we

Tim Beiko: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

Tim Beiko:we I think the the mistake we've made there is that we haven't had like a way for these breakouts to like.

Tim Beiko: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

Tim Beiko: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

Tim Beiko:every fork, at least looking at every existing working group, then assessing like, does this thing still make sense or not?

Tim Beiko:But yeah, I I just don't think it's possible to give you a commitment that's like better or stronger than that.

Tim Beiko: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

Tim Beiko:like, Yeah, I I'm very weary of just giving people the impression of.

Greg:When they're just there, isn't

Greg: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.

Tim Beiko: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.

Tim Beiko: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.

Tim Beiko:And you know you're free to make a proposal for.

Greg:For that system.

Tim Beiko:But yeah.

Greg: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

Tim Beiko:either we should start and

Tim Beiko: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.

Tim Beiko: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

Tim Beiko:discussed earlier. Cpres.

Tim Beiko: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

CPerezz:where we can actually have gas limits from I don't know between 60 million 300 million gas per block and just

CPerezz: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,

CPerezz: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

CPerezz: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

CPerezz: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.

Tim Beiko: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

Tim Beiko:basically, I, I wrote a post published yesterday on

Tim Beiko:on, like what I think the next step should be to

Tim Beiko:implement kind of the process we discussed for all core devs. We briefly discussed it already.

Tim Beiko: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.

Tim Beiko:There was also an eip

Tim Beiko:where the author was asking for some feedback from guests, I believe in the agenda, so I'll post it here

Tim Beiko:and then, aside from this, there's 3 more things.

Tim Beiko: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.

Ansgar Dietrichs: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

Ansgar Dietrichs: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: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

Trent: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.

Trent: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.

Tim Beiko:Anyone on the history expiry side.

Tim Beiko: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.

Tim Beiko:And yeah, we're already over time. We should discuss history expiry as well. But I don't think this call is the right.

Tim Beiko:Yeah, the the right time left to do it.

Tim Beiko: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.

Tim Beiko:great work, everyone, and talk to you all soon.

stokes:Thank you. Bye.

Łukasz Rozmej:Bye.

Chat Logs

Tim Beiko:https://github.com/ethereum/pm/issues/1500

stokes:🎉

Roman:On to the next!

Francis Li:congrats everyone!

Justin Florentine (Besu):or like idk, maybe take a nap?

Micah Zoltu:Replying to "or like idk, maybe..." No sleeping. Go build Fusaka!

SanLeo:Replying to "or like idk, maybe t..." aint no rest for the wicked

Justin Florentine (Besu):Replying to "or like idk, maybe t..." Normalize Being Human

MariusVanDerWijden:Replying to "or like idk, maybe..." After the fork is before the fork

Justin Florentine (Besu):Replying to "or like idk, maybe t..." Treadmills have off buttons

Will Corcoran:I’ll remove it RN

felix (eest):Replying to "or like idk, maybe..." there are no breaks on the eth train

Gary Schulte:Replying to "or like idk, maybe t..." or brakes

Tim Beiko:https://eips.ethereum.org/EIPS/eip-7935

MariusVanDerWijden:Replying to "or like idk, maybe..." https://www.youtube.com/watch?v=yI8dcvUPdco

felix (eest):Replying to "or like idk, maybe..." :(

Barnabas:First consolidation reaching the beaconchain in 13 mins on mainnet.

Ansgar Dietrichs:Micah on ACD ❤️ what a throwback

Justin Florentine (Besu):150 is a common discussion

MariusVanDerWijden:60M is already a stretch with what state growth is atm

Sophia Gold:Barring anythign unexpected, for sure should be higher than 60m

Ahmad Bitar | Nethermind:still dont think this needs its own EIP

Barnabas:I think it would be good to include default gas limit as part of the testing cycle. Peerdas itself is going to increase the general resource usage. Bumping the gas to 150M will most def. also increase the resource usage.

Barnabas:So it would be good to test the two together.

Barnabas:Replying to "still dont think thi..." without an EIP it wont be tested together with other EIPs

Łukasz Rozmej:RPC is horizontally scallable though, for example Besu has RPC fleet mode for state calls

Barnabas:Replying to "still dont think thi..." It needs to be formally discussed

Justin Florentine (Besu):yeah, infura is very "near head"

Tim Beiko:Replying to "still dont think thi..." Think of it as a Jira ticket @Ahmad Bitar | Nethermind 😄

Łukasz Rozmej:Replying to "still dont think thi..." @Tim Beiko now I'm sold!

Justin Florentine (Besu):how does testing feel about RPC represented in our coverage plan for vetting a gas number?

Micah Zoltu:Replying to "RPC is horizontall..." Not for end-users running their own node and being self sovereign.

Barnabas:50M gas requires 16GB+ machines peerdas on its own without bumping the blob limit also requires 16GB+ ram machines. The two together might require 32GB ram machines. (even for devnets!, thats a HUGE increase in RAM requirements.

Justin Florentine (Besu):your wallet

Ansgar Dietrichs:Replying to "60M is already a str..." with which aspect of state growth being the biggest concern? disk requirements? db performance?

Sophia Gold:Replying to "50M gas requires 1..." Aren't we currently recommending 32gb for validators?

Barnabas:Replying to "50M gas requires 16G..." yes, thats the problem. With large state we might need to start recommending 64 or even 128gb ram.

Ansgar Dietrichs:Replying to "60M is already a str..." there are other bottlenecks like snap sync healing phase duration, but that degrades as a function of state change rate, not state growth rate

Łukasz Rozmej:Replying to "60M is already a str..." maybe state sync is biggest concern, but I think the ceiling is > 60M

Justin Florentine (Besu):Replying to "60M is already a str..." are you specifically talking state, or overall space? history drop is buying us a lot of time

Marek Moraczyński:history expiry ;)

SanLeo:As a home node runner, yes, disk space is the biggest problem.

Barnabas:Replying to "history expiry ;)" we need to discuss gas limit bump together with history expiry

Francis Li:also for reference, base geth archival node is 32T now, rpc from quicknode / alchemy runs well

Łukasz Rozmej:Proper 4444 to the rescue!

Sophia Gold:It will be quite some time until the state alone requires >2tb

Ansgar Dietrichs:I think in terms of process, this seems like an in-depth discussion that should happen on dedicated calls

Barnabas:Replying to "history expiry ;)" they go hand by hand.

SanLeo:Replying to "history expiry ;)" will help, but only for so long

Tim Beiko:I mean, this is pretty much the most important thing to discuss here, no?

Barnabas:Replying to "It will be quite som..." validators don’t care about what the state size is, they care about what is the EL + BN together is.

SanLeo:Replying to "history expiry ;)" especially with a higher gas limit

Tim Beiko:Replying to "I think in terms of ..." If we decide to make raising the gas limit the main thing for Fusaka, we should agree to it here 😄

Justin Florentine (Besu):Replying to "It will be quite som..." RPC nodes do though

Ansgar Dietrichs:Replying to "I think in terms of ..." right. but the arguments seem to be less about whether we should try to do it, and more about the numbers

Tim Beiko:Replying to "It will be quite som..." @Justin Florentine (Besu) but are those really bottlenecks in the next OOM?

Storm Slivkoff:120GB/year is not a large amount with modern hardware and the recommended validator specs We have many years of storage runway

Micah Zoltu:Replying to "I think in terms o..." If I was king I would decrease the gas limit until state expiry was implemented.

Gajinder:Can we do just multi dim gas

Justin Florentine (Besu):but thats only at 60

Ansgar Dietrichs:we need to get to higher resolution on the individual bottlenecks. “state growth” is a bundle for several bottlenecks. disk size state db size state tree depth which of these are we most worried about here?

Micah Zoltu:Replying to "120GB/year is not ..." Why do we care more about validators than end users?

Storm Slivkoff:I think the real solution might be pricing IO operations based on tree branch depth…

Marek Moraczyński:what do you mean by extremely slow? Could you share some numbers @MariusVanDerWijden?

CPerezz:Replying to "we need to get to hi..." We need to collect data for this. But db size isn’t it.

Storm Slivkoff:Replying to "120GB/year is not a ..." Users are paramount. To support more end users we need more scale

SanLeo:If we go this approach, I think only SSTORE for empty slots should be prone to the gas market. Exposing SSTORE that doesn't actually increase state size to the gas market is a bad choice imo.

Micah Zoltu:I agree with Dankrad that we already have a bad state problem and we should decrease gas limit to address it. 😁

Justin Florentine (Besu):folks, we continue to make decisions about what our market wants based on subjective vibes.

Tim Beiko:Replying to "folks, we continue t..." What data do you think we need to make this decision?

Ansgar Dietrichs:Replying to "we need to get to hi..." sounded like Marius said just now that for geth it is

Justin Florentine (Besu):Replying to "folks, we continue t..." a marketing department.

Justin Florentine (Besu):Replying to "folks, we continue t..." a proper marketing department studies their market, and produces hard data for decision making

Micah Zoltu:Reminder: Stateless doesn't help RPC nodes at all. Nor does ZK Clients. Nor does PeerDAS.

CPerezz:Replying to "we need to get to hi..." Won’t be in the next 1-3 years. But if we go 60-100, we need due diligence. As we might get broken DBs sooner than expected.

Łukasz Rozmej:Replying to "folks, we continue t..." I'm in "don't give people what they want, give people what they need" camp ;)

Storm Slivkoff:Performance testnets to the rescue!

Micah Zoltu:Replying to "folks, we continue..." What people need: Censorship resistance and self sovereighty options.

Justin Florentine (Besu):Replying to "folks, we continue t..." neato; we don't have data on either

Francis Li:Replying to "we need to get to hi…" I would say it's database choice, LSM based trees cannot provide reliable performance guarantees with compaction, state growth isn't quite the problem for read access, it's more about how well the underlying database architecture can support reliable and bound read time

Dankrad Feist:database engineering can be improved? I really don't want to downplay that this is a hard engineering problem, but it really seems like this is a solvable problem (and has been solved by database and at least some clients)

CPerezz:Replying to "database engineering..." But you need data to know what your implementation can and cannot support. Such that you know what to improve. Atm it’s all speculation and some minimal benchmarks

Guillaume:Replying to "120GB/year is not a ..." You're ignoring the installed base, which is mostly 2TB. These are users we need to support, too.

Ansgar Dietrichs:right, to me gas limits are less about hard fork timing sprints, and more about continuous efforts. but it still makes sense to account for that when doing hard fork scoping, so we understand that clients will already be busy with that scaling work

Storm Slivkoff:Replying to "120GB/year is not a ..." If you don’t meet the recommended specs, it’s recommended that you upgrade

Tim Beiko:Replying to "right, to me gas lim..." Yes, I think this is really important

Justin Florentine (Besu):can we come up with a way to vett that gas-limit to state growth is linear/proportional? it's reasonable, but it's an assumption.

MariusVanDerWijden:@marek https://github.com/jsvisa/goleveldb-bench/blob/pebble/pebble-2.md RW goes up 10x in a 500GB set compared to a 100GB set

Sophia Gold:Replying to "folks, we continue..." Best way to do this is not marketting but bringing the actual users into ACD

Gary Schulte:Replying to "Reminder: Stateless ..." I appreciate the anti-capture perspective, but I don’t think RPC is the use case to push with. I am going to go out on a limb and say decentralized home stakers rpc usage is almost exclusively engine api

MariusVanDerWijden:Replying to "@marek https://git..." (very prelimiar numbers)

Micah Zoltu:Replying to "can we come up wit..." If gas price gets low enough, new use cases open up like backing up your MP3 collection to Ethereum.

Storm Slivkoff:https://www.paradigm.xyz/2024/03/how-to-raise-the-gas-limit-1

SanLeo:Replying to "can we come up with ..." Thats a new use case? I've been doing it for years

Ansgar Dietrichs:Replying to "right, to me gas lim..." that’s also why I don’t think these discussions e.g. around state growth are counter arguments: we only decide to put resources towards scaling, and then yes, responsible scaling means making sure any increase we recommend is actually sustainable

Ahmad Bitar | Nethermind:When do we expect to make final decisions on other CFIed EIPs?

Tim Beiko:Replying to "When do we expect to..." Ideally on this call, max next one

Marek Moraczyński:Replying to "@marek https://githu..." thx!

Guillaume:Replying to "120GB/year is not a ..." Ah, the windows 8 approach. That went well.

Storm Slivkoff:Ideal test data would be a performance test net with 2x or 3x the state size of main net

Ahmad Bitar | Nethermind:Replying to "When do we expect to..." didn't see this in the agenda, thanks

MariusVanDerWijden:I don't like SFI ' in gsomething that will only work if we add other changes into Fusaka

Justin Florentine (Besu):Replying to "folks, we continue t..." agree that might be better than status quo, disagree it's the best we can do

Tim Beiko:Replying to "I don't like SFI ' i..." I’d SFI it in Fusaka, to be clear

Justin Florentine (Besu):Billion gas blocks that just keep updating the same state slots in the Fartcoin contract.

MariusVanDerWijden:We could just re-run binance chain transactions on our perfnet

Ansgar Dietrichs:regarding usage patterns: that’s why it’s important we test both: current usage mix, just higher throughput individual worst case scenarios for different bottlenecks

Francesco:Why do we care that much about usage patterns? We can make storage as expensive as we think it needs to be

MariusVanDerWijden:And then we'll see that syncing is impossible and running with a "normal" sized node is impossible

Ansgar Dietrichs:Replying to "And then we'll see t..." that’s why we obv should only ever actually raise the limit after validating it’s safe

Tim Beiko:http://eips.ethereum.org/EIPS/eip-7938

Tim Beiko:Replying to "http://eips.ethereum..." Dankrad’s proposal ^

Tim Beiko:Replying to "http://eips.ethereum..." https://ethereum-magicians.org/t/eip-7938-exponential-gas-limit-increase-via-default-client-voting-behavior/23884/13?u=timbeiko

Micah Zoltu:Replying to "Why do we care tha..." I would have far fewer problems with gas limit increases if we increased storage costs by a matching amount so state growth remained unchanged.

Ansgar Dietrichs:Replying to "And then we'll see t..." so that includes that we need to have a checklist of different things to validate on these perf devnets. sync with heavy state should be one of them obv

Łukasz Rozmej:"Prediction is very difficult, especially about the future."

Storm Slivkoff:+1 for ambitious goals

Francesco:Replying to "[Full message cannot be displayed on this version]" I don't really understand why, if the concern is disk space. You say RPCs already drop history so they don't benefit from history expiry, but on the other end that we should worry about home nodes, which would hugely benefit from history expiry

Łukasz Rozmej:I'm all for under-promise and over-deliver than the other way around to be honest.

Justin Florentine (Besu):Replying to "Why do we care that ..." because bigger state dbs slow down

Daniel Lehrner (Besu):Engineering normally means test first, measure then do the action. That EIP is doing exactly the opposite

Justin Florentine (Besu):yes, haphazard

Francis Li:If you aim for the moon, even if you miss you may hit a star 😀

Storm Slivkoff:Replying to "Engineering normally..." The first gas EIP is conditional on testing

Bastin:+1 Marius

Barnabas:Replying to "If you aim for the m..." or you keep flying forever into emptiness, more likely than hitting anything 😄

Justin Florentine (Besu):we're at least not ready for review on ACD

Ahmad Bitar | Nethermind:how do we define the goals though?

Micah Zoltu:Replying to "If you aim for the..." And likely run out of oxygen before you get there. 😉

Sophia Gold:Without an EIP how can we make geth update their config?

MariusVanDerWijden:Geth will update their config as soon as we thing its safe to do so

terence:isn’t that the point of an “informational” EIP?

Tim Beiko:Replying to "Geth will update the..." Do you think we can come to consensus across clients about what “safe” is?

Ansgar Dietrichs:Question: Should we consider having a small repricing EIP in Fusaka? Poll all the clients in the next 2 weeks what specifically they are most worried about to go to say 100M gas, and then just make those specific things more expensive in Fusaka? so e.g. make state growth 2x more expensive. because otherwise next opportunity is Glamsterdam, so scaling might be blocked at that lower safe limit for the next 12 months or longer

MariusVanDerWijden:Replying to "Geth will update t..." I think so

Justin Florentine (Besu):Replying to "Geth will update the..." we did for 36

Tim Beiko:Replying to "Geth will update the..." Then that’s basically what the first EIP says 😄

Tim Beiko:Replying to "Question: Should we ..." I think we should be OK adding those much farther in the process

Dankrad Feist:if we find a roadblock we can delay the schedule

Bastin:Replying to "how do we define the..." run on a testnet. monitor stats like bandwith, cpu, ... you also have the hardware requirements to check against.

Sophia Gold:Replying to "Geth will update t..." I was being a little cheeky since geth didn't have 36m until long after mainnet

MariusVanDerWijden:Replying to "Question: Should w..." This will take longer than two weeks, but yes

Ansgar Dietrichs:Replying to "Question: Should we ..." “much farther” we are already weeks after the PFI deadline though, right?

Gary Schulte:A balanced middle ground between ambition and reckless is to target gas limit informed by a specific predictable scaling algorithm and commit after testing.

Justin Florentine (Besu):Replying to "Geth will update the..." is geths gas limit not user-definable?

Ansgar Dietrichs:Replying to "Question: Should we ..." but yes, if we think they are easy to add late, happy with more than 2 weeks

Micah Zoltu:We could 10x the gas limit in Fusaka and also 10x all costs, then write EIPs to reduce costs from there. I think someone in Ethereum R&D Discord suggested something like this.

Luis Pinto | Besu:So if there’s a way out what’s the difference from considering it in ACD calls going forward if it’s sustainable?

MariusVanDerWijden:Replying to "We could 10x the g..." Problem with this is maybe the 21.000 const. You can't really change that

Storm Slivkoff:Replying to "if we find a roadblo..." Enshrining goals in an inspirational publicly visible way

Ansgar Dietrichs:wait in 3 months? won’t we already have Fusaka client releases by then? :-)

Sophia Gold:Replying to "Geth will update t..." We're talking about the default config

Carl Beekhuizen:Replying to "if we find a roadblo…" Because there’s a really strong default to strive to reach the next goal

Micah Zoltu:Replying to "We could 10x the g..." Why not? Too many people have it hard coded in their tools?

MariusVanDerWijden:Replying to "We could 10x the g..." yes

Tim Beiko:Replying to "Question: Should we ..." Did my comment answer it @Ansgar Dietrichs ?

Justin Florentine (Besu):Replying to "Geth will update the..." thats my point. you don't have to convince the geth team to endorse a new limit, you can convince the operators.

Ansgar Dietrichs:Replying to "We could 10x the gas..." I think we decided we will be more willing to break hard coded gas price assumptions going forward

Ansgar Dietrichs:Replying to "We could 10x the gas..." we have been telling people for the better part of a decade now that such assumptions are unsafe

Csaba Kiraly:My preference is to do the research, and then write informative and preferably widely agreed posts about expected scaling achieved by this and that change, rather than setting a goal timeline.

Tim Beiko:Replying to "Geth will update the..." No, but it’s a nice signal if ACD can actually recommend a new default each fork

MariusVanDerWijden:Replying to "wait in 3 months? ..." Thats my point, we need time to find and fix the worst cases and to propose and ship eips for them before Fusaka

MariusVanDerWijden:Replying to "wait in 3 months? ..." Otherwise we will delay fusaka for this

Łukasz Rozmej:@Tim Beiko maybe some context how gas increase is being tested to be safe?

Ansgar Dietrichs:Replying to "Question: Should we ..." yes, I was only surprised that you said 3 months - I think even a small repricing will need some testing work, and so it can’t come *too late* into the fork lifetime

Mario Vega:We should at least make a list of the concerns on gas increase so we can start to think how to test it

Sophia Gold:Kamil is on holiday I believe

Justin Florentine (Besu):Replying to "Geth will update the..." right. so users have options - campaign across the community to raise a limit on their own, or CONVINCE acd to raise it. that is marius's point, if you rely on us to vet something as safe, you have to trust us and give us the time to do so

Tim Beiko:Replying to "Question: Should we ..." Yeah, I think for Fusaka we should base it on PeerDAS progress

Storm Slivkoff:Performance test nets with 2x or 3x the state size of main net will clear up almost all uncertainty here

Tim Beiko:Yes, this is exactly what I feel the first Info EIP suggests

CPerezz:Replying to "Performance test net..." That’s one of my agenda items (hope we get there)

Micah Zoltu:Replying to "Performance test n..." It won't address the state growth concerns of RPC nodes.

CPerezz:Replying to "Performance test net..." But 100% agree.

CPerezz:Replying to "Performance test net..." @Micah Zoltu But ill clear a lot of other concerns like DBs breaking or IO regression in performance

Ansgar Dietrichs:given that scaling is being elevated to the main EL priority going forward, I think we need to 10x our sophistication around how we validate throughput levels. all the bottlenecks we track, all the different load scenarios we run, etc.

Ansgar Dietrichs:Replying to "given that scaling i..." I’d be curious what people think the best way is to make progress on ramping up there

Justin Florentine (Besu):and we should solicit tests from community - let them define the aspects of the network they want to protect in the face of the gas increase

Ansgar Dietrichs:“suggest some repricing” - just reiterating that these have much much longer lead times than out-of-consensus client implementation improvements

Tim Beiko:Replying to "“suggest some repric..." Why though?

Micah Zoltu:Replying to "“suggest some rep..." I think because coordination is hard.

Ahmad Bitar | Nethermind:Replying to "and we should solici..." not a big fan of the community focused approaches. Give community what it needs and not what it wants.

Mario Vega:I think that CPU testing and CPU edge cases could be done in EEST because they don't need a huge state, so the idea would be that if you have such cases in your unit test set, it would be great we port them to EEST where all clients can consume them

Łukasz Rozmej:our ModExp repricing EIP is based on this scaling testing by the way

SanLeo:Replying to "“suggest some repric..." Is it a larger amount of coordination than any other hardfork?

Ahmad Bitar | Nethermind:Replying to "our ModExp repricing..." yeah, we should start with SFIing, EIP-7823 and EIP-7883

Łukasz Rozmej:@MariusVanDerWijden that EIP is not for you, it is for public (community)

Ansgar Dietrichs:Replying to "“suggest some repric..." @Tim Beiko what makes you think that repricing changes are easy to add much later into the process? I think the implementation and testing overhead they come with is similar to other small-to-medium sized features

Tim Beiko:Replying to "@MariusVanDerWijden ..." I think it’s for both though

Francis Li:Replying to "given that scaling i…" talk to L2s, I'd imagine they've experienced all sorts of limitations from scaling up gas limit or reducing block times already

Vasiliy Shapovalov:I don’t have a good grasp on what we can raise or not but my 2 cents is I’d much prefer gradual raise (best option - block by block, though it will require cleint change) if we hit problems we likely hit small problems first and on a minority of clients/hardware

Micah Zoltu:Replying to "I don’t have a go..." Changing the default will achieve that.

Ansgar Dietrichs:Replying to "given that scaling i..." but who will go speak to the L2s? what’s the structure here? who is leading these efforts? etc

Ben Adams:Dankrand's potentially needs work on mechanism; so would be against that right now; but for the more general one

Anders Elowsson:Replying to "I don’t have a good ..." I think he implies an even smoother curve

Tim Beiko:Replying to "I don’t have a good ..." @Vasiliy Shapovalov one concern is that some bottlenecks don’t show up linearly

Tim Beiko:Replying to "I don’t have a good ..." e.g. the 10MB limit

Isidoros Passadis:Replying to "I don’t have a good ..." yeah i'm unsure about this tbh. I think we hit some critical threshold here and 1-2 clients (or even worse, all) shit the bed and all of a sudden we're not finalizing

Vasiliy Shapovalov:Replying to "I don’t have a good ..." yeah I’m talking like over 2 weeks or months

Tim Beiko:Replying to "I don’t have a good ..." Ah okay!

Vasiliy Shapovalov:Replying to "I don’t have a good ..." one other options would be canary raise

Anders Elowsson:Replying to "I don’t have a good ..." Simplest would likely be to adjust the update step?

Vasiliy Shapovalov:Replying to "I don’t have a good ..." e.g. raise on 1 slot of epoch

Isidoros Passadis:+1 for additional collab around "how do we define and assess safety as a community" (research + eth/client devops + node ops)

Micah Zoltu:We can resolve that with @lightclient's EIP from long ago that made the gas limit capped, but validators could lower it.

Vasiliy Shapovalov:Replying to "I don’t have a good ..." e.g. the 10MB limit would imo show up linearly

Vasiliy Shapovalov:Replying to "I don’t have a good ..." fullest blocks would be rare

Łukasz Rozmej:Replying to "I don’t have a good ..." don't worry there are dedicated people testing it, right now

Ansgar Dietrichs:should the monday testing call alternate between scaling and “specific fork feature work”?

Vasiliy Shapovalov:Replying to "I don’t have a good ..." testing is great but there’s no second mainnet, really

Vasiliy Shapovalov:Replying to "I don’t have a good ..." some stuff can break besides the clients - relays, builders, explorers etc

Barnabas:Replying to "should the monday te..." corporate needs you to find the differences between these two things.

Justin Florentine (Besu):anyone know what Reth thinks?

Roman:we are supportive of including it

Ansgar Dietrichs:Replying to "should the monday te..." yes it’s probably a bad proposal, I am not a frequent monday call participant

Tim Beiko:https://eips.ethereum.org/EIPS/eip-7934

Łukasz Rozmej:Replying to "I don’t have a good ..." if you test worst edge-cases than mainnet average case is lighter than those

Łukasz Rozmej:Replying to "I don’t have a good ..." we can always go back to clients building blocks :D

Łukasz Rozmej:Replying to "I don’t have a good ..." We will test explorers

Łukasz Rozmej:Replying to "I don’t have a good ..." if builders can't keep up they are crap :D

Vasiliy Shapovalov:Replying to "I don’t have a good ..." testing is also not mutually exclusive with very gradual raise/canary raises

Mikel Cortes:keep in mind that blocks are compressed before sent with snappy

lightclient:is this for fusaka?

lightclient:when will we be done specifying fusaka?

Csaba Kiraly:At the EL side, we can limit the max blobs that can go into a single Type 3 transaction.

Tim Beiko:Replying to "when will we be done..." Again, ideally today modulo “blockers to increase the gas limit”

Ansgar Dietrichs:I don’t love it from a “principled fee market design” point of view, but I think it is a reasonable pragmatic choice for Fusaka

Paweł Bylica:OMG, Can't wait for tests for this EIP :)

MariusVanDerWijden:Replying to "when will we be do..." 3 days before the fork, as usual

lightclient:I think we should try to SFI the contract size increase then

Ansgar Dietrichs:Replying to "I don’t love it from..." we can always replace it with something more principled in a later fork, if it ever becomes a priority to do so

Vasiliy Shapovalov:if we can for say 50% of bugs limit the impact from chain stop/losing finality to losing finality/missing 2 slots why wouldn’t we do that

Tim Beiko:Replying to "when will we be done..." @lightclient yes, once we sort out the gas stuff, we should cover the last CFI’d EIPs

Justin Florentine (Besu):very interesting, so you're out of consensus in isolation

Sophia Gold:Is this necessary if we also add a calldata gas dimension?

Micah Zoltu:So currently you'll miss your slot if you build 10MB block, because everyone will de-peer you.

Tim Beiko:Other CFI’d Fusaka EIPs: Considered for Inclusion EIP-5920: PAY opcode RIP-7212: Precompile for secp256r1 Curve Support EIP-7762: Increase MIN_BASE_FEE_PER_BLOB_GAS EIP-7823: Set upper bounds for MODEXP EIP-7825: Transaction Gas Limit Cap EIP-7883: ModExp Gas Cost Increase EIP-7907: Meter Contract Code Size And Increase Limit EIP-7917: Deterministic proposer lookahead EIP-7918: Blob base fee bounded by execution cost We should determine if there’s anything else we want to SFI today, especially for fusaka-devnet-1

Micah Zoltu:Seems like an obviously good EIP and should be included. Explicit constraints are good.

Sophia Gold:Replying to "Other CFI’d Fusak..." 7212?

Csaba Kiraly:Changing these limits are really easy at the network level. What is more interesting are the techniques we introduce to handle big messages more efficiently (erasure coding, etc.)

SanLeo:Replying to "Other CFI’d Fusaka E..." 5920 would be great

Justin Florentine (Besu):i like it. seems prudent, easy to implement.

Łukasz Rozmej:Nethermind for it

Jason Carver:Does increasing the gas limit and adding a distinct block size limit make it more awkward to optimize when building a block?

MariusVanDerWijden:yep agree, should include

Justin Florentine (Besu):besu too

lightclient:Replying to "Other CFI’d Fusaka E..." 7907

MariusVanDerWijden:Replying to "Does increasing th..." yes

Justin Florentine (Besu):Replying to "Does increasing the ..." yes, adds a dimension to optimize over

MariusVanDerWijden:peerdas

Ben Adams:One of the two blob fees

MariusVanDerWijden:modexp repricing

Marc:Replying to "Other CFI’d Fusaka E…" 7883

Mario Vega:Replying to "Other CFI’d Fusaka E..." We cannot SFI without tests btw

Anders Elowsson:Do you have na

Anders Elowsson:Any questions on EIP7918?

SanLeo:Replying to "Does increasing the ..." Yes, but as Ben said, there's no reasonable situation where you'd hit the limit, even at 110MGas

Justin Florentine (Besu):besu was fine with modexp when last reviewed

Ahmad Bitar | Nethermind:I think we SFI 7212, 7823, 7883, 7917, 7918, 7934

Ansgar Dietrichs:Replying to "One of the two blob ..." we looked into it some more from the research side, preliminary consensus is that we all prefer Anders’ EIP (7918)

Ansgar Dietrichs:Replying to "One of the two blob ..." small caveat: there were still some very small adjustments we might want to make. what would be the timeline until the spec at least for the next devnet would have to be final?

MariusVanDerWijden:worst case at 60m for geth would be ~3 seconds

MariusVanDerWijden:both would be nice

Tim Beiko:@Mario Vega do you know which actually have tests vs. Not?

Mario Vega:Replying to "@Mario Vega do you k..." Only Pay opcode has a PR at the moment

Łukasz Rozmej:I see testcases in 7883

lightclient:it’s almost like we need another stage between CFI and SFI lol

lightclient:pre-SFI’d

Justin Florentine (Besu):or just.... have discipline?

lightclient:what’s that

Tim Beiko:The difference between getting right on the first shot vs. Having to iterate towards it

Justin Florentine (Besu):isn't writing the tests part of "consider" ing?

Toni Wahrstätter:Replying to "or just.... have dis..." nah, i prefer a new acronym

lightclient:i think we should softly agree on what we want to SFI here, do the first devnet with just peer das, then plan on the next devnet having the SFI’d eips

Justin Florentine (Besu):or just allow CFI'd into devnet?

lightclient:i think SFI in devnet is good

Justin Florentine (Besu):ok, so SFI'd but can't get on devnet till tests exists and pass? 01:14:43 Ben Adams: modexp is highest priority for higher gas block size would be next priority for higher gas

Justin Florentine (Besu):besu is pending

Luis Pinto | Besu:Replying to "ok, so SFI'd but can..." Makes sense, waste of resources

lightclient:7212, mod exp eips, 7907

lightclient:most of the CFI’d eips are little protocol changes that users don’t care about

lightclient:don’t need to rerun pectra

Justin Florentine (Besu):can someone write that down?

Ahmad Bitar | Nethermind:Replying to "I think we SFI 7212,..." this is my personal list.

Ahmad Bitar | Nethermind:Replying to "I think we SFI 7212,..." not sure nethermind agree

Ben Adams:ACDT?

Justin Florentine (Besu):or even do it async

Justin Florentine (Besu):it's just a bookkeeping problem

Roman:next Mon sounds great

Som - Erigon:Monday

Sophia Gold:7212 is the one users constantly ask for

Ben Adams:EIP-7934 is size https://eips.ethereum.org/EIPS/eip-7934

Ben Adams:7938 is expontial gas increase :)

Mario Vega:We can share a cost of testing doc maybe tomorrow, it could help clients decide

Justin Florentine (Besu):we're generally open to everything CFId

Marc:how about modexp EIPs in first devnet? seems to be wide consensus on these eips and they help with gas limit scaling

Daniel Lehrner (Besu):Why would we CFI something and not consider it for SFI?

MariusVanDerWijden:Otherwise theres no need for a fusaka devnet, only peerdas we already done many times

jochem-brouwer (EthJS):For smart contract devs I would also really want to get PAY in

jochem-brouwer (EthJS):Antwoord verzenden naar "For smart contract..." Will also take upon me to write tests for it

jochem-brouwer (EthJS):Antwoord verzenden naar "For smart contract..." I have a PR open which I want reviewed for PAY https://github.com/ethereum/EIPs/pull/9590

Ansgar Dietrichs:this was a criterium for CFI, not for SFI

Łukasz Rozmej:Those micro-EIPs on EL won't delay PeerDAS

Anders Elowsson:Please get in touch if you have any questions on EIP-7918

Justin Florentine (Besu):ok, so whatever is on CFI'd and has tests, into the 2nd devnet after a PeerDAS one?

SanLeo:Replying to "For smart contract d..." @jochem-brouwer (EthJS) I'd like to help on PAY, maybe you can DM me on discord and we can chat?

jochem-brouwer (EthJS):Antwoord verzenden naar "For smart contract..." Yup will do, whats your handle?

SanLeo:Replying to "For smart contract d..." @sanleo

Justin Florentine (Besu):fair. some things that are CFI'd need specs

Ansgar Dietrichs:I think everything we CFI’d so far is “small enough we are okay with adding to fusaka” with the caveat of “if one of the less important ones causes delays, it’s out”. so now we are only talking about ordering of when to bring them over into the main devnets

Justin Florentine (Besu):modexp(2) + pay?

Ansgar Dietrichs:agreed (with what Tim just said). but now is not the time anymore for just general “is this scope small enough to not delay peerdas” conversations

Ahmad Bitar | Nethermind:We will get an ordered list on Monday

Justin Florentine (Besu):love it

Justin Florentine (Besu):CFI'd list from this https://eips.ethereum.org/EIPS/eip-7607 plus EIP-7934

Sophia Gold:Jumps are actually much cheaper than they're currently priced (proposed to reprice to 1 in glamsterdam) so I'm not sure this is necessary at all

Guillaume:Removing static jumps is older than ethereum itself

nixo:fyi there’s interest in the yt chat about getting a quick update on history expiry, think barnabas also added to to the agenda at the beginning of the call. would be nice if we have time to cover briefly

lightclient:i think adding something more along the lines of 2315 for static jumps makes more sense

lightclient:it’s not broken, people use ethereum all the time 🙂

Justin Florentine (Besu):need an EVM roadmap working group

Sophia Gold:Much more worthwhile to add all the SWAPs and DUPs imo

Łukasz Rozmej:we need proper agreenment if there will be EVM in the future (or replaced by something else)

Storm Slivkoff:completely agree with Marius

Ahmad Bitar | Nethermind:Replying to "we need proper agree..." that will take a long time, we should not base short term decisions on the potential of a replacement

Ansgar Dietrichs:Replying to "need an EVM roadmap ..." I am optimistic that will happen as a consequence of EOF. but not for Fusaka, but for a coherent plan for 2026 and beyond

Łukasz Rozmej:Replying to "we need proper agree..." I'm leaning pro-EVM, but I think I might be missing some perspective

Luis Pinto | Besu:But I agree with Greg that it’s hurting adoption

Sophia Gold:Replying to "we need proper agr..." I think it's too early to know but we will discuss a little in Berlin

lightclient:Replying to "But I agree with Gre..." hurting what adoption?

Ansgar Dietrichs:Replying to "need an EVM roadmap ..." just need to figure out whether the best format is EF-led or acd-led

Luis Pinto | Besu:Replying to "But I agree with Gre..." Limits what you can do in ethereum and language evolution

Justin Florentine (Besu):Replying to "need an EVM roadmap ..." i appreciate that being said out loud, thank you!

lightclient:Replying to "But I agree with Gre..." how? languages don’t need to use dynamic jumps

lightclient:Replying to "But I agree with Gre..." you can replicate static jumps by ensuring push op before every jump

Łukasz Rozmej:Replying to "need an EVM roadmap ..." EOF makes transpiling/compiling lot easier, that is my main benefit from it.

Storm Slivkoff:It’s not clear to me that a working group would actually solve the fundamental roadmap issues of uncertainty and disagreement

Ansgar Dietrichs:this conversation should happen async

Barnabas:I’m happy to work on eof-devnets btw.

Barnabas:so if there are adjustments to be made, it still can be tested there.

Tim Beiko:https://hackmd.io/ob66NuW9QBORHLz7emhSCw?both

Tim Beiko:https://hackmd.io/D12VBHdMSU6y_vcqWcJV_g?both

Ansgar Dietrichs:is this about the consequences of state growth, or state size? because they are subtly different

CPerezz:https://hackmd.io/ob66NuW9QBORHLz7emhSCw?both

CPerezz:https://hackmd.io/D12VBHdMSU6y_vcqWcJV_g?both

Ansgar Dietrichs:Replying to "is this about the co..." can have both networks with large state, but low rate of continued growth. or, high growth rate, but for now still small state. or ofc both large state and continued large growth

Trent:I can make a final mention for Pectra Pages

Sophia Gold:history expiry update?

Tim Beiko:https://ethereum-magicians.org/t/community-consensus-fork-headliners-acd-working-groups/24088

Tim Beiko:https://ethereum-magicians.org/t/for-an-acd-platform/24098

Ansgar Dietrichs:2nd research call is next wednesday, ethereum-o-clock topic will be the short-term EL scaling features, with focus on Glamsterdam

Tim Beiko:https://eips.ethereum.org/EIPS/eip-7636

Tim Beiko:Anything else 😄 ?

Ansgar Dietrichs:Replying to "2nd research call is..." I’ll put a link with details into the acd channel once we have them

Tim Beiko:Anyone for history expiry?

Ansgar Dietrichs:Replying to "2nd research call is..." call is also on the protocol calendar

Tim Beiko:To re-iterate: pre-ACDT, please share your sorted list of the CFI EIPs, we’ll finalize fusaka-devnet1` scope there 😄

Ansgar Dietrichs:Replying to "Screenshot 2025-05-08 at 17.32.51(1).png" time to close this tab it seems

Trent:Replying to "Screenshot 2025-05-08 at 17.32.51(1).png" You can do ittttt

lightclient:what is going on with history expiry?

Justin Florentine (Besu):devnet deployment priority

Trent:Yay pectra!! 🦒