All Core Devs - Execution #247

Transcript

Nixo: Good morning, good morning. We're already live, but we will wait a few minutes to get started.

Okay, let's, let's go ahead and get started. Welcome to All Core Devs Execution number 247. Today's October 8th. And we have successfully undergone. Glamsterdam fork on the Sepolia, Testnet, which is exciting. Good job, everybody. Does… do the pandas want to give a, An update there?

Barnabas Busa: It was a boring fork.

Stefan Starflinger: Yeah. Good.

Barnabas Busa: Congrats, everyone.

Stefan Starflinger: Do you want to give the update Barnabas or?

Barnabas Busa: Yeah, it was pretty boring.

Stefan Starflinger: you.

Barnabas Busa: Yeah. Do you have anything else to add?

Stefan Starflinger: It went pretty well, I think. I would also say. And, gas limit ramped to 200 million now, which is nice. After the fork, that went pretty well, I think. Just some clients needed to update.

Nixo: Great. Do we have, any other, any other things that we want to cover before talking about scheduling the Hoodi fork?

Stefan Starflinger: I have some stuff for Mainnet shadow fork for benchmarking, but we can do that after also.

Justin Florentine: Regarding, ePBS, I was curious if we could elaborate a little bit on maybe builder-searcher participation on Sepolia? Are we seeing much?

Barnabas Busa: We're seeing a few builders coming online, but nothing crazy. I'm actually a bit surprised. That's how little builders are participating in Sepolia. We currently have 5 builders active. You know, 4, one of them just exited, so… And all of those are, I think, either Titan or Nico, and I'm not sure who the rest of them are. So it's… All a bit, quiet. On to our Sigma Prime, so… Really, the big players are not yet, not yet on Sepolia.

Justin Florentine: All right, thanks.

Barnabas Busa: And we are also seeing that lots of local-built blocks are I'm not sure why. I guess we're just not, not having enough, Proposal preferences to send out, or… Quite uncertain, because we don't draw a better Forsopolia, but maybe we should. Not sure.

Nixo: Great. I think that we can talk about scheduling the Hoodi Fork then. I have two slots, here that I think would be, good. They are both. the last week of October. One is Monday the 26th, and one is Tuesday the 27th. Do… right now, I have defaulted in that, in that pull request to Monday. Do clients have any preferences, about those two times?

Barnabas Busa: One thing I would like to raise is, this is a week before Devcon, and the earlier we do, the more time people will have to fly. So, ideally, I think we should do this as early as possible, and I would vote for Monday. Even though it's a Monday.

Nixo: Great. If no pushback, then we will, schedule that for… Monday the 26th at 1742 UTC. When do we need to get releases out for that? Tuesday does look like a lucky day. Can we say a week before that? Or is that too… do we need more time than that?

Barnabas Busa: I would do at least 10 days.

Nixo: 10 days. Okay, let's see if we're doing the 26th. So, by next Friday, then. By October 16th, that would be 10 days. That gives, the full week of the 19th through the 23rd for people to update their nodes. Tight to get releases out by next Friday? What is… what feels like the earliest, potuz?

Potuz: It's tight on both ends. It's for the operators, for ourselves to send releases. I mean, it's probably fine, we are probably ready to fork on the 26th. But we have, like, staking pools that are… that are deployed on Hoodi, like, all of the home stakers are deployed on Hoodi. It's a much more complicated fork to have than just Sepolia, where we know every validator. So if you give them less than two weeks advance on releases, I presume we're gonna have problems, and if we give them more than… I mean, if we give us less, the two weeks, we're not going to be able to put them. Right? So we should, like, get a release today or tomorrow?

In order to be able to be ready for Hoodi. And besides anything, I really think we should have, for Hoodi, we should have a plan, since that's not permissioned, we should have a plan, we should make sure that we can, sync from unfinalized, and that we have flags to disable the P2P builders, and to fall back to the trusted builders. Or fall back to local building, we should have these, these flags ready on clients.

Nixo: Do we not have those flags right now?

Potuz: Prysm does not have a way of disabling the P2P stack. Immediately. It's an easy flag to add, we can add it, but the thing is that… and we don't even need to test it, it's a very simple change. But, again, these things add up. We are talking about how… if we want to give two weeks for, say, like, Rocketpool or Lido, then we need to cut up the release tomorrow, and we're gonna be rushing today, therefore, to merge all of these things. I really think it's unrealistic. I'm pretty sure we're gonna delay the release, and they're gonna have less than 2 weeks.

Barnabas Busa: When do you propose we do the fork then? Perfect.

Potuz: I do not know. If we do… if we do fork on the 26th or the 27th, which I… I mean, again, this… the dates are fine by me, but then the question is, do we want to give this operate… these large operators, less than a week, or… to… to have releases, or do we want to risk Exactly what happened in Sepolia. We, like, the majority of clients had a patch release right before the fork. Because the release that came out in the blog post was not the release that actually needed to be used.

Nixo: Is there a… is there a reason that, these large operators need more than, say, a week to update their notes? Besides just, like, us making sure, like, cat herding and making sure that they're actually doing it. Because I feel like we could commit to… to… Bugging people more aggressively to update their notes, since it's… a quick operation for them, and it is not such a decentralized validator set as, like Holeski, for example, was.

Barnabas Busa: I think if the 16 is fine by clients, that should give 10 days. I think 10 days is more than sufficient for everyone to update. And if it's not, then they can update afterward.

Nixo: james.

Barnabas Busa: probably 80-90% of the validators sell easily. So it's not like we're going to have a non-finality scenario.

Nixo: James, what docs, state that we give 2 weeks?

james: I'll need to find it, but… That's… that's from memory. I thought it was written down somewhere. It was 2 weeks.

Nixo: Okay, I can't… I… the only two weeks that's in my head is the two weeks between… between testnets, but I can't. Yeah, I'm not sure. For now, can we say, Client releases by the 16th, that gives 10 days, for… for, operators to upgrade, and that is 8 days from now. Is that too tight for clients to cut releases? I I Ivan.

Iván | ethrex: Yes, I'd like to try to move from Monday to Tuesday. most of the ethrex team will be flying, on… between 26th and 27th. We are making a couple of days to Europe, because to avoid a plus 35 hours flight to India, so… in that day, we'll be flying. Maybe if we can do it Tuesday, will it be better?

Barnabas Busa: Yeah, but this argument is also a pass to a bunch of other people that will be flying on Tuesday to Wednesday. So, yeah, the question is… there… whether there would be more people playing on Monday, or whether there would be more people playing on Tuesday.

Nixo: Daniel.

Iván | ethrex: ER.

Nixo: Can y'all put in the chat whether you guys will be flying towards the beginning of the week or the middle of the week? So that we know. If a Monday or Tuesday fork would have more clients available?

Iván | ethrex: Okay, fair. That's fair.

Nixo: Any chime in. People have no idea when they're flying yet. You guys bought your tickets yet? Not flying Monday or Tuesday. We'll be meeting in person, not flying. I will point out that the Tuesday slot is significantly later than, than the Monday slot. The… Tuesday slot is… like, 8 PM UTC, and the other one is… 11 Utc.

Let's, let's default to this Monday slot. Yeah, it's… I think better to give a little bit more time. Okay, great, we will schedule that for Monday, then. And, somebody wanted to just note that, we are confir… to… we should confirm that we did decide that the gas limit is changing right on the fork… fork epoch, correct? If that's not anyone's understanding, please speak up now. Great. For Hoodi and Mainnet, then, we are planning the gas limit change. on the fork epoch.

Okay, anything else, Glamster? I think, Stefan, did you have… One more thing that you wanted to say.

Stefan Starflinger: Yeah, So basically, I did the mainnet shadow fork, and the idea was to do one for benchmarking. And I went or it went a little bit wrong and right at the same time. So it raised the gas limit by an insane amount. To allow for deploying large contracts. But it ended up never lowering the gas limit amount. And we also went through, the Gloas fork in the mainnet, shadow fork, which was also not necessarily intended. But it went very, very smoothly, which is very nice. So we have a mainnet shadow fork. fork transition, already, and we had, builders, during the fork, which was also very nice straight away. And now, we're using that shadow fork, for Snap 2, testing, because there are large blocks, and large BALs.

And that's probably a good edge case, to test with very large payloads. But I'm planning on relaunching the benchmarking shadow fork. So this ManageHeaderFork 1 will run till tomorrow end of day, and I'm planning to relaunch it beginning of next week and to do to make sure it runs more smoothly this time. That's basically it.

Nixo: Great, thank you. Do we have anything else on Glamsterdam? Alright, almost done with this fork. Then we will move on to Hegota. And the first thing, I wanted to go through with Hegota was, We have, so far… dealt with quite a few of the EL, EIPs, but I want to make sure that we, are… Thinking about, fork scope, especially, given desires to speed things up, use AI to, speed things up. So I wanted to give a few minutes to Dan, for talking about, the complexity assessments that they are doing on, EIPs that are being proposed.

Danceratopz: Hey, good morning, everyone. Can you hear me alright?

Nixo: Yes.

Danceratopz: Okay, perfect. Seems like the monthly laptop boot worked for the audio. Okay, can you see my screen?

Nixo: Yep, looks good.

Danceratopz: And I'll just share the link to the slides and this site that I created in the chat. So, thanks Nixo. Basically, I've been mucking about a little bit with, LLMs and EIP Markdown, and trying to see whether the complexity assessments that we do on the steel team can be automated and whether that data sort of gives us any signal that could help with scoping or with Devnets and whatever. And that's what I'd like to show you today. So what is a complexity assessment? Basically. a complexity assessment is like a questionnaire for people that love EIPs, and they can go through this questionnaire, and they can answer questions that tell you what this EIP changes about ethereum. But it's limited to the execution layer side at the moment. So these

Basically, the goal is to try and sort of estimate how much effort it would take to implement the EIP, but scoped to the execution layer. And this has only existed since Glamsterdam. Where Mario, like, created this template with 24 questions or criteria. And you can give a score from 0 to 72 to some EIP that you get as input. And we did this for Glamsterdam, human evaluations at that time, of course, it was already AI-assisted. And what would what would one of these questions look like? You've got example in the bottom right hand corner. So like, basically, this is a quite simple example. did we add in? Did the EIP add any new opcodes? And then you can score it based on whether that was the case, and how complicated these opcodes were, or how many there were. And then you've got some kind of indication of how hard that would be to implement and test.

Umm. It seemed that the first version of the template had a few pitfalls. And for example, it didn't really take into account across the EIP interaction very well. And Mario did a sort of retrospective. like evaluation of what the Glamsterdam EIP testing did. and then calibrated the original template against the effort that he saw in in our repo. And so this added four new criteria, and the range grew. But in particular, it catches, captures cross EIP interaction as well. And. like Mario and I were talking about this and like wondering if it's like actually useful. I mean, who knows? Like, you know, it's quite hard to sort of assess these things. How how much signal does these does this thing give? And we sort of vibed a little bit and had the idea that what we could do is we could use LLMs to basically do a retrospective study.

of these EIPs, sorry, of all EIPs and all previous forks, in order to really see whether. we can somehow see that the amount of effort that this EIP questionnaire tells us, like, does it really, like, represent how much time it takes to ship the EIP? And… So I think that's pretty — so yeah, basically, I'll just say I just reran this late last night, and I reran it with Opus 5.5. And it's ran, like… so that it may… Claude will basically, like, evaluate any EIP, and for the retrospective assessments, it tries… I've picked dates. from the EIPs markdown and commit refs, which represent when, like, fork development started or scoping stopped. and took a snapshot of the EIP. And asked Claude to do his best to not apply his knowledge afterwards in order to evaluate it at that point in time.

So somehow sandboxed. It's not perfect, but It will have been trained on that data, but it is what it is. And when I did this study like 6 weeks ago with like Soul 5.6 or something, and, it seemed to over evaluate a lot of things, and it seemed to get things really blatantly wrong. So I just I've made a proposal to improve the template again, but it keeps the criteria so it shouldn't really change what human rights, but it tries to disambiguate the language so that an LLM. Can be a bit more precise about its evaluation. You can have a look in more detail afterwards, but it's just basically trying to keep the wording a bit more,

a bit more precise to avoid disambiguity for the robots. So I think, at this point, I will go away from my slides, because the site's a bit nicer, and so basically what I… I posed the question, does, like, the complexity… the accumulated complexity for the entire fork, does it somehow track the time to mainnet and you can see if you count. So from all these evaluations you get all these scores, you get a score per EIP, and then you can accumulate all these scores and add them all up, and you get a tally. And the blue is basically what we could tell at the time of the scoping cutoff. And then the orange here is what was added later on that we didn't foresee or what we felt was necessary afterwards.

And then here you can have a look, of what… so every color here is a question in the assessment, and, you can see what which forks kind of contributed. You know what what complexity contributed to the effort of of those of those forks. What's interesting is, if you normalize each fork to 100, the breakdown is is kind of strangely similar. And I think that's mainly because a lot of our work is, is kind of dominated by edge cases, by cross… so, cross-EIP interactions, by things that forgot to get specified. From security and performance in particular for the benchmarking effort and gas repricing for Glamsterdam And so a lot of the effort for a fork is dominated by these things. On the left-hand side, you kind of see more concrete things like, we got a new precompile, we got a new opcode, we changed gas constant. And these are sort of the less predictable things, I'd say.

If you go to the individual forks and EIPs, there's a lot of information here, and it's just to, you know, give… I think it's useful to look at. It should be taken as one data point. It's, You know, it's not absolute, and it needs work. But basically to answer our question, what with that data, the amount of complex. So On the x-axis, you're looking at the complexity score for the whole fork. Why not? accumulated. And then… on the Y-axis. What you see is for time from the first to execution layer client devnet until mainnet. How many days that was. And yeah, I mean, doing a lease squares here doesn't really make much sense, but it's kind of fun. So I did it anyway. And if you kind of what you can do in this little widget is you can. You can like you can.

you can like click or remove or add the Ips, and then you can see more or less where this complexity moves, and where where that would that where that would land. So you can have a play around with that. But basically, what's shown at the moment is all SFI and all CFI VIPs. At the moment, that's 14 EIPs. That's a lot. And we're already at the most complicated fork before we would CFI any of the other PFI EIPs. I think that's pretty much it. I would just like to say one more thing, and that's more… More of an outlook, about this work, so… all these numbers, are we optimizing, like, for the right thing? And, I mean, these provide signals, but I don't think we should be focusing AI tooling on these numbers at all. Like, I don't think it should be the main focus. There's a bigger fish to fry here, and I think we should now start running this stuff

regularly on EIPs as they come into ethereum EIPs. And use this tooling to actually provide signal about Whether there are contradictions. Underspecified aspects, inconsistencies between a required EIP and the EIP being studied. and help provide tooling to EIP authors in order to to then improve their specs, which will then improve and help people's lives, implementing respectively agents lives and implementing these specs. All right, that's about me. Thank you very much.

Nixo: Thanks very much, Dan. Mark?

Mark Mackey: Yeah, did you have a look at actually implementing these EIPs? Because, like, for example, EIP7549 was, like, in Electra, where we changed the attestation, and from a spec point of view, it was quite simple, but from an implementation point of view, it was quite difficult, so… Like, are you… are we including just… the… Time there as well. to actually… You know, put this in clients.

Danceratopz: I think it's a fair question. And I mean, for all this study, I asked myself lots of questions like, what am I doing with my life? Like, is this worthwhile? at the end of the day, the LLMs are getting better every day, and, essentially, a complexity score could just be, in the future, a one-shotted EIP, right? Like, why not just implement it and then see what happens? And I mean, currently, we don't automatically do an implementation. We could think about that as things get better and better. What I can say is today that the SPEX team on the EL side has implemented, or they've got PRs up for every CFI the EIP. Unfortunately, we haven't updated the human complexity assessments that correspond to those implementations.

That'd be nice to do. It's just a lot of work. I guess it's just another thing to do. But it would be… Worthwhile, in my mind, to do that in order to as a verification against against the the LLM outcome and and basically see if How good the match is. So you can find some human scores, like, on the site, but they're You can't really compare it one-to-one, because they're on an older version of the spec.

Mark Mackey: I don't even mean human scores. I just mean the difference between like how quick is this thing to write up a spec for versus how quick is this actually to write an implementation in all the clients.

Danceratopz: So I see where you're getting at, and I think that probably the most important thing would be to have a dashboard which shows whether the spec is worth implementing yet. So… I would like to have what you what you're suggesting. But I suggest that basically the first… The first step is really to do a sweep over this over the my pound spec to validate it so not necessarily to get a number, but to get The fact that, this line of spec contradicts the value listed in the table, for example, and just silly things like that, or or more reasonable, more important things, or For example, the, some downstream EIP stays consistent with its dependent EIP. So, for example, with frames and keyed nonces, the keyed nonces EIP

if something changes in 8141, we get feedback immediately that the dependent EIPs need updating, and that, you know, if someone forgot to do it, for example. I would say that's the first tooling that I'd like to have. And then… Then you can go for the fully automated implementation, and then you can Do a human review. I hope that answers your question somewhat.

Nixo: Great. Does anybody else have any comments on that? I think that this is a really useful place to start out, to… Make sure that they're… Stomachs aren't bigger than our… A. whatever the phrase is, so that we don't over-scope this fork, because we do have a lot of EIPs, still to scope. With that, we will move on to the next agenda point. I wanted to give, 2 or 3 minutes to Lukasz, who wanted to talk about, actually speeding up and better parallelizing these works.

Łukasz Rozmej: Thank you. One comment about the tool. I like the tool. I think it's probably can be iterated upon and made better, even if it's already useful today. And I agree that's actually giving LLMs EIPs to prototype, not only to look at the spec. Made them do better assessments, because they often, discover things while they're doing it. So, my… going to my point, which is somewhat similar, that I would prefer to try to accelerate and doing more hard forks per year, doing more work in parallel, doing more things. What inspired me? So, for example, in Nethermind, we are currently implementing EIPs as soon as they get CFI'd. We already have 100, 50 PRs related to Hegota, most of them already merged, I think 12 are open.

we can go… really fast and even faster. This is, this is not a problem for us, so implementation is somewhat solved. And I think the… the main problems for speeding up is actually coordination, testing, and other things, which were always really, really hard. But we are… doing better tools. One of them we just saw. We have forecast which actually streamlines a lot scoping. We have initiatives like Bantek initiative to standardize tracing, which I think should be looked upon and studied by more people how it works. I can… send the link in the chat, I will drop it now. Basically, he's leading that, he's coordinating on many levels and getting things done. I think we should create more different tools that, for example, would help, EIP champions to be more involved in both,

implementation to some extent, and testing, and other things like that, so we should involve more people, especially for not the biggest EIPs, so not the ones, not the headliners that have all the attention, but Things that are smaller, it's good to have more people owning that, but we need to give them more… build for them, and give them more tools to… to easy come and easy have a full picture of the state of the EIP, of the state of the test, on everything. We can also automate a lot of things, like, I don't know, test is failing, and LLM already opens a PR with a fix for the client team to look at. That's a very easy thing to do.

And if we have a good dashboard for that and good notification systems, I think we can like shorten the feedback loops by huge amount. I don't want anyone to be replaced by LLMs and AI. I think that the people should still steer it, and should decide it, and should review it. I am reviewing hundreds of of PRs per month now in Nethermind. So I still think this is… this is how it should be done, and I don't… we shouldn't give the steering wheel away, but we… we can do a lot, a lot, a lot more, and especially focusing on this kind of tools that would streamline things, that would make things Very easy to spot, that would allow less…

Like I said, for example, more EIP champions to be involved, and more like a product owner role, rather than just writing a spec and forget it. which sometimes happens. So those those are kind of my thoughts. I don't have like all the specifics, and I'm happy to start a debate and Maybe prototype something on my own of this kind of tools if I have a good idea how to, what is needed. That's it.

Nixo: Thank you, Lukasz. Before I move on to Mark and Justin, I'm just gonna say I'm gonna timebox this. I don't think that we should have this. too much of a conversation here. I think this would be a really good topic for Mumbai, for in-person working, but, yeah. Mark?

Mark Mackey: Yeah, I… Kind of just also want to echo the sentiment, because… Like, I can remember back in the Electra fork scheduling, when we were considering MaxEB, like, at the time, just due to the resources that we had, we basically had one client, Prysm, that had, like, even been able to… had the bandwidth to, like, look into it and start to implement it, and we had… Just at least at first, it was just potuz who had had like any kind of handle on how complex MaxEB would be, and then… So we kind of went with that because it was all we had, and then later we kind of reassessed that, and that's how Max EB ended up getting in. But the, the point is that like.

Yeah, we are in a different regime now. Like, it's totally possible to have every single EIP all the, like, at least initially spec'd and through implementation. Even if it's AI slop, and then rated against each other. And that's going to realistically be more work than. like we've ever had in the past. For… for as much as you can say is, like, it may not be correct, it's not a… it's not foolproof, and all of that kind of thing, it's still significantly more, like, vetting than we've basically ever had. before, so I think, yeah, the taking advantage of that would help significantly.

Nixo: Justin. Maybe.

Gary Schulte: You're muted, Justin.

Justin Florentine: Great, alright, let's try that again. So, yeah, two points I want to make. You know, I'm generally. averse to speed for speed's sake. However. I do see the writing on the wall, and I do think that there's plenty of capacity here, to… To take that up. So, I think I'd like to frame this question around, great, we have this new capacity that's been unlocked. Do we have specific things that we want to do with it, or do we just want to randomly accelerate? So, for example, PQ. I think that's probably the only thing that I see on our roadmap. that is a clear and present danger, and that if I had unlimited capacity to accelerate, I would accelerate in that direction. So I would like us to be specific about this, and follow-up point to that is, like.

Lukas, I liked your write-up, it was very good. The idea of kind of just going towards 4 hard forks a year of the same size. to me seems a little arbitrary, and I'm sure that's really, you know, that's just a starting point, that's just a, you know, an idea. But, you know, maybe we couch this in terms of, let's just accelerate, let's just see how fast we can go, without forcing a target that we feel that we have to meet, because there's just… there's just so many unknowns here. So yeah, I just wanted to float that out there, thanks.

Nixo: Oops. Luis?

Luis Pinto: Yeah, I wanted to raise a point about the specs and the use of AI writing specs. I think we need to be, like, specific, simple and concise on the spec side, because that's really what drives AI implementations. And, if we are vibe coding specs and, implementations, then, aren't we kind of losing a bit, the side of client diversity that are interpreting, the specifications? on each own, and being critic about the specification, so which allows us to improve, and make the best version of the EIP yeah, I… I would like, like, to hear, like, how do we solve this problem, and, what's your thoughts about that?

Łukasz Rozmej: So, client diversity doesn't… shouldn't be considered in terms of the core spec, because we… clients need to agree on the core spec, actually, so it's actually the other way around. All the testing we are doing is to make sure that clients do agree on the core specs and all its edge cases, so we don't want diversity of spec, because those are consensus issues.

Ben Adams: Just to follow up on your point, Justin, PQ, for instance, I don't think is an easy thing To accelerate with AI and maybe in terms of implementation and, how it works. But I think the main bottleneck, bottleneck there is decision making and. We can't really do that. With AI.

Justin Florentine: And I think that's kind of my point here. Like, I think that's… That's actually a huge problem. Right? Like, how long does it take us to schedule a hard fork? That's not a thing that we let AI do, and I'm not sure that we should.

Ben Adams: Yeah, but there's a lot of admin, and there's a lot of stuff that can be automated around it. That's… them. Yeah, that could accelerate it. But yeah, the decision making we still have to do.

Nixo: I'll mark, and then let's let this be the last comment.

Mark Mackey: Yeah, that's exactly it. Like, for initial assessment, before we make any decision, like, it's either we have I mean, maybe if some dev is really driven for one EIP, then they can go further and look at it like a human, but when it comes to, like, the myriad of EIPs that we have to consider for a fork, it's… like, an initial vibe-coded spec and vibe-coded implementation is fine for, like, an initial score and initial assessment, because the alternative is nothing. Because we don't have the resources to vibe, or to spec out and thoroughly look at everything. But then once we have something to help us wrap our heads around all… everything that we face. Then obviously we're gonna go thoroughly look at and do things.

Nixo: Great. I feel like this is fruitful conversation, and I hope that it continues at Mumbai, because… Lots of lots of things are changing in this. In this land. We can move on to, Scoping. The first thing that we have is, from Ben, there is… So we have 11 EIPs left in, in the… PFI status, but Ben has a new EIP that he'd like to talk about, adding to the PFI list.

Ben Adams: Yeah, so this, we already did half of this, the original, in, Glamsterdam, which was increasing the contract size and the other half was, to charge based on the contract size. And we didn't do that. So this is reintroducing that aspect, and this comes from the testing we did. And it showed that… this… this will potentially be our new ceiling based on how many contracts we can load, and based on disk speed. So the idea is we… we… I would like us to reconsider, not necessarily, you know, CFI it for the fork. But reconsider the metering based on contract size.

Nixo: Cool. Does anybody have any opposition to adding this to the PFI list, assuming that we will not make a decision about it today, but we'll make a decision about it on the following call, which is our last scoping call? Cool. Okay. Then we'll move on to the, 11 EIPs that need decisions. I'll share my screen. See? Make sure I choose the right screen. Alright, can you guys see my screen?

Jochem Brouwer: Yes, yes, yes.

Nixo: Great. Okay, I'm gonna… Put the chat in it, too, so that… Livestream can see that. Okay, Where are we? Okay. So, I've ordered this by… Sort of what seems like it has consensus, versus what we need to talk about. Because we've already… we've already had these conversations. And then what seems like an easy DFI. So the first three, that we're looking at, there was pretty okay consensus. These ones, look like they all have, based on. Dan's assessment, medium complexity, so I want to make sure that we're not just throwing everything into the fork. Let's start with the highest, the highest rated one, 5920.

This got, Decent. Decent ratings for most clients, with most clients in support just saying. It's… Something that we would like, but we're not sure that it's urgent. I am gonna, just… So, for 5920, this is the last one that we had that was the highest rated. Are we okay CFI-ing this one? Is there any, push for DFI-ing it based on keeping the scope smaller? Oh, zoom in? Okay.

So… Ben.

Ben Adams: I'm keeping the scope smaller, I mean, it's not, it's not an SFI, so I don't think there's a problem. Okay. We can always… we can always do another round where we… we DFI-based funds.

Nixo: Okay, I'm gonna move to CFI 5920, then. And then we can move on to 8151, so ecRecover. Just got a pretty good. Reading from all the clients except for Erigon and Reth. Does anybody want to say anything on this one?

CPerezz: This should be paired directly with SETCODEFROM both together, as the combination of both is what allows you to transition into post-quantum, without no longer relying on your ECDSA and taking all the funds and positions and whatever you have with you, so… If we CFI, we should CFI both together.

Nixo: Okay, great. We have from Besu and Erigon C tiers on SETCODEFROM. Do they want to say anything about those ones?

Justin Florentine: I can go for Besu. We discussed this a little bit further. We are more open to it, but not enough to actually change it to B. I think that might change as we pair it with, other things, I think, that, you know, were just mentioned. As well as, I think, deactivating self-destruct, that goes in, that becomes a thing that we care more about as well. So, I treat us as a C+?

Nixo: Great. Is this…

Lightclient (Matt Garnett): Just ask, like, what… Sorry, hello. What's your… what is Besu's preferred approach for EOAs to migrate to post-quantum?

Justin Florentine: I don't have an answer to that right off the top of my head.

Lightclient (Matt Garnett): Because to me, like, SETCODEFROM is, like. a critical part of like what I'm imagining is the path for EOAs to become post-quantum. So that's why I feel ranking it so highly is important. But if you guys have an alternative approach that you prefer, like, we could discuss that. I just think that, like, we need to figure out in Hegota how EOAs can become post-quantum, and if it's not this, then we should decide that.

Justin Florentine: So I think our current thinking is kind of some of the existing models Might be sufficient for it. But we don't have examples that I can give you as an alternate path for that, so I don't think I'm prepared to answer that question. We recognize the point, though, for sure, like, if we were to prioritize like, a pure PQ fork. That for sure would go in there. We also have trouble teasing out the size and complexity that comes with some of these ratings as well.

Nixo: Carlos, do you still have your hand raised?

CPerezz: Oh, never mind. My client make the point, so that's it. Yeah.

Nixo: Okay, so as… as I understand, this is, some… Some path to, PQ readiness is dependent on this. And so. CFI-ing it would create that path, whereas DFI-ing it leaves no path.

Justin Florentine: Yeah, let me clarify Besu's position here. We don't want to be a blocker on this. This is kind of our, you know, our ranking of it amongst everything else. So, like, if everybody else thinks that this should go in, we're certainly not going to put up a fight.

Nixo: Cool. Since these go together, then are we comfortable CFIing both of these? That's 8151 and 8298. Any opposition? Cool. So, they're… the next two are also, somewhat paired, TCREATE and Self-Destruct. this was talked about on the last call. Milos, who agreed to champion this, who unfortunately could not be at the call today, gave, an update on TCREATE. And I think that there was… pretty good response, seeing that, this was, something that is being introduced in Glamsterdam and doesn't have,

doesn't have a… this fix is something that isn't being introduced in Glamsterdam. So… First of all, does anybody have, any comments about pairing these as well? Great. I think the only things… the only teams that we didn't get, responses for… for 8360 were ethrex, Geth, and Reth. Do… do they want to weigh in at all? Because otherwise, this is… Quite highly rated.

Iván | ethrex: On the ethrex side, sorry, Nixo, I couldn't give you my opinion in time. We are okay for, tiering it up to a B. I was thinking between a C and a B, but I'm okay not doing it. I would start thinking on doing it later in the process, after we figure out all the main ones, the main EIPs.

Nixo: Okay, yeah, that's… that makes sense, and that's, I think generally how the… CFI works as we move things into SFI and put them in devnets. CFIs for both of these? Any… Opposition to that? Great. For the next ones, the next ones are… have a little bit more contention, and so I'm going to ask, that… that we default to DFI-ing, unless there is opposition. The next ones… I think our… 7709, 877… 8077, and 7666. These are. ones that have flags on them, or have been, flagged as not urgent by clients. So, let's start with 70… 7709.

Yes. Does anybody feel like this is urgent, and that we have to get this in, given the scope that we're already looking at for Hegota?

Ben Adams: Yeah, so I recently looked at. Sort of a light client working off BALs as the data. And, BLOCKHASH is one of the things that's problematic because you still need the previous 256 blocks. Whereas if we include… if we change to this form of BLOCKHASH, so you're reading from the storage, then that will be in the BAL. Umm. and also in the data, so you won't need the trailing 256 headers, so I'd like to… Movement Nethermind's vote up from B. To… to A.

Nixo: Ignacio?

Ignacio Hagiopan: Yeah, as an EIP champion, I agree with what Ben said. It was kind of the underlying purpose of proposing this for Hegota. I particularly asked Dragan from Reth, which is the team that decided to DFI this, and I think his point was that it wasn't really a strong opinion. So, maybe if he's here, or anyone from Reth is here. Can't give… its view about this, if it is, like, a strong DFI or they don't really care. About it.

Nixo: Alright, And we can move to, CFIing this one as well. Any opposition there? Okay, then… 8077. This was really mixed support. I, I'm gonna ask if anybody… Csaba?

Csaba Kiraly: I let you ask the question.

Nixo: If anybody, opposes moving this one to DFI, just to… Keep the scope a little bit smaller, especially given that there were no There was only one, S tier for this.

Csaba Kiraly: you Yeah, so… Why I think it's important. we are making networking changes on the CL, but on the EL, we have the mempool, and the two visions of how The transaction volume that we are increasing should get on-chain, and one is… Where does anybody have the private feeds? And the other is supermempool. And this is to support the mempool region in which we are increasing the capacity of the mempool. And, the underlying reasoning is that we should increase… improve the networking of the mempool as well. And yeah, it's outlined in the EIP with specific reasons that are. I was naming four. But in general. With the current mempool, everything is fine if we have all the bandwidths on us, all the bandwidths that we need.

But we are absolutely not prepared to operate in a regime when we have a node which is falling back. So this is this is tool. To make that work. Since we are raising the gas limit already now, and we don't know what we will do in Hegota, but I don't think we will reduce it. I will be… strongly in support, but I'm… I'm the champion of it, so that's not… not a surprise.

Nixo: Lukash.

Łukasz Rozmej: So 2 things so if node is falling back, we can actually temporarily disable a transaction pool on it and actually don't do anything. If you're now you're you have time to catch up. There's no point of Downloading transactions from other things and just focusing on catching up first because you cannot validate them properly. I was debating actually to did this kind of EIP exactly this one like 4 years ago. I decided not to back then, because, looking at our transaction pool rules, just adding sender and nonce is not enough. To actually have a full picture, if we should request this transaction, does it have a real good chance of, of going into our pool, or being better than the transactions we have, or not? So, I would rather do it all-in or nothing.

So nothing is to DFI this, or doing all-in, so actually transmitting a bigger kind of transaction Header where, each transaction pool can Preemptively assess if this is the better transaction than it has or not, and based on that, download that transaction or not, and sender and answer is not enough there.

Csaba Kiraly: Okay, I see. So, standard analysis is enough for many things. It doesn't have the fees. The fees is something we have been discussing along DCIP, and as I understand, you also looked at it previously. I'm absolutely open to look into that. Also, others are… I'm happy to look into that. So, it came up in many other discussions that the fees might Might make sense, obviously, depending on transaction size and everything. There's a size where you just send a transaction, because it's almost the same, but… Yeah, we can definitely kind of make it more sophisticated in that sense. Sometimes there is a field of that sophistication, so, you know, we have to… We're going to little bit.

But happy to work with you.

Nixo: Any other comments? Okay, what I'm observing is, is… like, tepid support here. Nothing urgent and nothing, not, like, wide consensus. I… I'm gonna move to DFI this. Does anybody have… Strong opposition to that.

Csaba Kiraly: Yes? I don't understand your, kind of… decision process, but other than that, no. So I would… I would either CFI or defer, if it would be me.

Nixo: Lukasz, does Nethermind want to move its, its ranking at all, based on the conversation?

Łukasz Rozmej: If we made it more robust, I could give it a B. Which is fine and potentially fine in fork.

Nixo: Do any other clients want to weigh in?

Justin Florentine: I can elaborate a little bit on why we like it. We see a future where, you know, filtering these things in the mempool becomes a lot more important, so, we have a future utility angle to our B-Rainy.

Nixo: Okay. Then we will move to CFI that one.

Ben Adams: Yeah, also with, frames, potentially putting transactions in the mempool costs a lot more, so. It might be interesting from that respect.

Łukasz Rozmej: I would just ask to do a deeper analysis if anything beyond gas prices should also get in that, especially counting frames and other stuff. So it will be actually robust and future looking.

Nixo: Cool. The next one we have on the docket is, 7666. This got… A's from Besu and ethrex, and C's or D's from all other clients. Does anybody want to say anything about this one?

Łukasz Rozmej: I could also revise it to be I actually found One edge case where, where this precompile I had to optimize around it, so making it I'm removing it kind of way would also solve this, so it is a bit of a technical depth.

Justin Florentine: Basically looked at this as kind of a healthy vertical spike. So we do think on the merits, it's useful, interesting, and fairly cheap. However, when we get time to actually sizing and considering it, whether it should go in the fork. Again, we consider it a useful vertical spike, so… The urgency is… Aligned with our appetite for paying off tech debt.

Nixo: Any other comments around this one?

Ben Adams: Yeah, I assume there's still an appetite to, if feasible, move more precompiles in the future. To EVM, so this would be like a useful, as you said, Justin, to prove that mechanism in a very low risk way.

Nixo: Felix.

Felix Lange: So, I'm somewhat strongly against this EIP. The main reason is that I think, like, we can… we can talk about EVMifying precompiles that actually do something, but this one is not… I mean, it's a trivial thing, so it doesn't really make sense to… Like, spend resources on… Like.

Ben Adams: But.

Felix Lange: this.

Ben Adams: That's why, that's why it's low risk.

Felix Lange: I mean, low risk in the sense that, like, I'm… We will not, I mean, if this gets done, we will not implement it, basically. We will just keep doing what we're doing now. And just change the gas price. So there's no… I think it's kind of pointless. It's better to talk about the other ones where we're trying to reprice the precompiles based on their EVM code, but for this one, it's a bit… it's more… this… I feel this is more signaling EIP than actual technical implementation EIP.

Kevaundray Wedderburn: What does that… What does that mean? Like…

Felix Lange: I mean, as in, like, what's the benefit of doing this? It's just to signal that we are able to use the EVM to implement this trivial operation. We might… if we're gonna use the EVM to implement something that used to be precompile, we should do a real one, like a precompile that is actually You know, does something.

Kevaundray Wedderburn: Right, I guess the point is we've never done this before, so this is a low-risk way of doing it. Like, you don't need to worry about the bytecode being incorrect or anything like this, because it's a simple identity precompile.

Felix Lange: I mean, the general benefit of changing a precompile into EVM code is that it de-risks it, so it is kind of a… low risk operation as long as you, you know. I mean, if it has a bug, it has the same bug on all the clients. So then it's kind of like we're just stuck with the wrong behavior, and that risk is not removed by this EIP shipping. So there's no risk in running the EVM instead of a precompile, because it's just a normal contract. So the only thing we'd be doing is remove it from the table, and then instead, you know, make it call the actual bytecode, which we're doing all the time. So there's no risk in changing a precompile into something else.

Kevaundray Wedderburn: I mean, I think.

Felix Lange: Anyway…

Kevaundray Wedderburn: Technical risk to changing a precompile to make it use bytecode. Like there's the risk of the bytecode being wrong, but then there's just the technical risk of changing, like adding code to the address where it is. And this sort of removes the bytecode risk, because the identity precompile is, like, pretty simple. But there's also… yeah. We just haven't done this before, so there is a technical risk of just adding code at that address.

Felix Lange: There's no risk in that. Like, on the implementation level. I mean, may… some… some contract somewhere might assume that, you know, it can check that this address has no code, but for… yeah. We're not gonna discover these cases by changing the identity precompile either. So I think this argument is not valid.

Kevaundray Wedderburn: Yeah, I'm just reading the comments, yeah, I don't think we should spend too much time on this. Yeah, if he M. I agree that implementing it would be faster than, DFI.

Nixo: Alright, Let's, let's move this one to CFI, and we can… I do want to point out that there is another part in this process that we added, we talked about it in Svalbard, which is prioritizing the CFI EIPs, and devnets would move through that priority list. So, we still can have the conversation about whether or not it's… worth it relative to the other CFIs as time goes. Thank you, guys.

Lightclient (Matt Garnett): Wait, why are we not DFI-ing it?

Nixo: It seems that it is very little complexity, and that there is more conversation that needs to happen. I'd be comfortable deferring it to the next call if people want to take another look.

Łukasz Rozmej: So Jochem has a point on potentially changing the gas cost, which is potentially breaking compatibility, if I understood it correctly.

Jochem Brouwer: Yeah, so 2 points, the EIP says in security considerations that, the, as no new new functionality is introduced or made cheaper. Well, that's actually not the case because this actually makes certain inputs. More expensive. And the other thing that is also not in the EIP is if this, Contract then gets removed from the default warm accounts, so This at least needs to get some attention on the spec side.

Łukasz Rozmej: Okay, I would then DFI it because it's not worth it.

Nixo: Felix.

Felix Lange: I mean, this thing copies memory from A to B, like, why are we messing with this?

Nixo: Okay. Then moving to DFI. You guys give me one DFI. I'll take it. Okay, moving on. The other… the last three, I think, are more… There's much less, or much bigger spread on these ones. I don't have a lot of context on the ML-DSA verification. Does anybody want to talk about this one?

Ben Adams: I think there's. There's a little bit of comp. complexity or disagreement, because I think the spec proposes three different things, and some people are happy with one, I don't know, somebody else can speak to that.

Kevaundray Wedderburn: Yeah, I think I brought up this argument that, even if we were okay with lattices, it doesn't really make sense to me that we'd be, CFI-ing three different versions of a particular signature, scheme. like. We're not gonna use all of them, and this argument that maybe one country needs to use the weaker version, while another needs to use the stronger version doesn't… At least that's not a strong argument for me. Outside of that? I think we should definitely look at. what the gas cost is in the EVM bytecode. I'm personally not okay with, CFI and a lattice-based scheme. But I still think we should look at what it costs, just for people to do it, like, in EVM bytecode.

Nixo: You know?

Danno Ferrin: So a couple of questions there. So, first, the overarching… my overarching motivation for this is cryptographic agility. We need to have multiple signature families available for people to put their funds in. We can't… locking in on just one is, is, is incredibly risky, in my opinion. As far as why all three, because people need choices. We can lock down into one of them. But to directly address Kevaundray's question, what's the cost of doing this in the EVM? It's about a million, and they've had… it started out at 5 million, and it's gone down about a million, and that includes, a lot of AI performance improvements to get the cost of doing this evaluation in raw EVM.

And that runs into a couple of major problems, because 4337 limits, validation to 500,000 gas, and 3160, which is BASIS, response to frame limits validation to 100,000 gas. So, doing this in EVM-only bytecode locks out two of the major account abstraction solutions that are going to be out there. So that's one of the reasons why I think we need to look at specifying what it would look like if it were to be. a precompile One of the strong arguments brought against it is, well, look at what happened with Blake, and look at what happened with RIPEMD. Nobody's using those. Look at, you know, BLS, you know, nobody's using those, it's relatively low impact. But I think that's the wrong comparison. What we need to look at is P256.

And that has been, brought around… that has been brought up over 8 to 10 years before it was finally adopted in various levels to various people. The reason it was brought up is because it's the one that financial regulators are asking all of their clients to use. So, one potential middle ground for this, is maybe not to ship it directly. in Hegota, but instead to reserve one of the 100 series precompile ranges, like was done for P256. Get a specification for it, get the tests written into the Ethereum compliance tests, so that if it were shipped, this is what it would look like, it's known, this is the address, it is standardized. And that'll avoid the problem we have with P256, which is where there are about 2 or 3 different definitions.

There are different, reactions to the various, you know, how do you respond when the answer's no? Do you respond with a hash? Do you not respond with a hash? The standardization, putting it in, like, the 100 series makes it a lot easier to, if the… if Ethereum may not decide suddenly it does need it later, to just turn it on. It also creates space for… for roll-ups and L2s to decide, well, even though Mainnet doesn't like lattices, we like lattices because our customers like lattices, so we're going to go ahead and turn it on. So, from my perspective, that is something that I would like to, rather than just turn our nose up at lattices because we don't like the math behind it, we need to make room for all users to use the whole of Ethereum.

Nixo: Antonio.

Antonio Sanso: Right, yeah, I mean, probably people know already my opinion, and as you probably know, we have been running bi-weekly. Breakout rooms on this topic. We've been looking at the beginning at lattices, but with time, we've been moving away from it for several reasons. I can, I can summarize some of this. Start from the end, we have, some testnet called Daisugi, where we actually are running, at the moment, a version of SPHINCS with aggregation. So it's gonna be really, really cheap on gas. And this is actually, thanks to aggregation, of course. And this is actually one of the issue with this, with this. EIP is the fact that it's really short-sighted. Namely, like, there is no plan to scale this. If literally every user of Ethereum is gonna use this

this precompile, the network is basically frozen, or, like, the gas is gonna spike, like, the level that we were at the 2021. This is the first issue. The second issue is, like, zkVM compatibility. We're… the moment is… I mean, the gas is really mispriced at the moment. If we keep in consideration that the fact that we're gonna move to zkVM, this is gonna be really a total bad price at the moment. And the last but not least, I mean, I have 10 other reasons, but I don't want to take all the evening, is basically, like, we are introducing this new assumption in Ethereum at really bad timing. We have seen what happened in the last weeks, months, introducing this right now.

I don't know if it's the best things. Once we have a solution that actually works, and it's really scalable with hash, and it's really conservative. And I stop here for now. I can answer some questions more offline.

Nixo: Thank you guys. It seems like a clear lack of consensus about the specific path forward, so I'm going to, propose that we DFI this one. There seems to be a lot of support for that in the chat. Great. Alright, 8116. Replace cumulative receipt fields. Low ratings from Besu, ethrex, Reth, mid-tier Erigon, and supported by Geth and Nethermind. Does anybody want to say anything about this one? Ben.

Ben Adams: It's it's not useful, so it's just waste. Because in order to work out, in order to use it, you've got to request two transactions. And then subtract them, so… Umm. It's… yeah, it's technical debt removal. And also, network, bandwidth.

Nixo: What is the complexity of this one? Very low. ethrex or baser. Do you guys want to say anything? You guys. Rated RF.

Justin Florentine: We agree with Ben's and Lukas's assessment that this is technical debt clearing, and that's why we put it in C tier. Sure, it's great, we love it, we should do it. But where does it fit amongst everything else? I don't know, about the middle?

Iván | ethrex: Yeah, we don't see it as a priority, so we just DFI'd it. We don't see any.

Nixo: Okay, great. I think this is… An easy CFI, but put at the bottom of the priority list, item, then.

Justin Florentine: We'd be fine with that.

Ben Adams: I'm not sure if it was proposed this time, but I'd… like, log… removing the logs or… To me, seems like a more important one. Sorry, not the logs, the, bloom filter.

Justin Florentine: Bloom filters, yeah, and we rated that one higher as well.

Nixo: See? Oh, yeah, that's CFI. So, okay, we can. Put that one above that, then. Alright, we've got one more to consider today, and then 7907 next week. Do we want to use the last 8 minutes, to get a decision on persist warm access sets across reverts? Looks like ethrex felt strongly against it. Reth and Erigon were mildly against it, and the rest was lukewarm support. Interesting that it's authored by Dragan, and only a C tier from Reth.

Ben Adams: I have a bit of 8037. Ptsd, and… This. This feels like revisiting that wound.

Nixo: Felix.

Felix Lange: So I just want to give some context on our decision here to put it in A tier. So we did analyze this EIP and we, all of us, couldn't remember why. we implemented it this way. Like, why are these, why is it reverted? We just cannot figure it out. So this is something to consider, is that it's a bit unknown for us. There may… the original, author. may have… like the original authors of this warm… Access… construct might still remember this, but honestly, I don't think anyone really remembers, like, I think it was just because it would mirror how others tracking works. So then they were just like, yeah, it should work like… other storage access works, and that also gets reverted. But as far as we can see, there's no real downside to changing it.

However, it does introduce complexity to then have both paths in the client, so there is this… forever argument, I guess. So it doesn't reduce complexity for the moment. But it's just, like, for us, it was impossible to see. Is it correct or not, or what are the implications?

Nixo: Does anybody want to sway either direction here? CFI, DFI? It seems… Luke warned so far, and given that we already have a ton in the, in the fork, I would lean towards DFI-ing.

Ben Adams: I'd lean that way because it's changing, it's making What is changing is quite deep at fork boundary. I don't know. I don't know if it's worth it.

Nixo: Okay, I'm clicking the DFI button. All right, that gets us through all of these. We have… I think there are two informational ones still. We can, talk about those next call, but we're going to have the whole next call to, talk about 7907 and whatever other Hegota scoping things that we want to talk about. Does anybody have anything else? that they want to bring up today. I think there was one more item which Andrew Codeup added, which was just. sort of pressing on Justin Drake's. Bunker Mode tweet yesterday, does Andrew want to say anything about that? I think the idea was, paying, I don't know, paying attention to that in terms of Hegota scoping. If there's nothing else today, then I think we can close up.

Pooja Ranjan: If I may take 30 seconds, just wanted to quickly bring up the Glamsterdam Ecosystem Readiness Checklist for Devs Attention. That is to collect feedback from enterprise. They wanted to understand and share their. results from testing on the Sepolia testnet, so if this checklist looks good, we can perhaps add it to the Ethereum PM repo, the PR is already added there, and share it with the enterprise to collect the feedback.

Nixo: Great, thank you Pooja. Yes, scoping was definitely fast. I… Gonna contribute a lot of that to Forkcast and Mark's work. Thank you, guys.

Justin Florentine: Good work, everyone.

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