![Execution Layer Meeting 247 [2026-10-08] | ACDE 247](https://cdn-images-3.listennotes.com/podcasts/ech-institute-podcast-ech-institute-inc-9qpsxXdLTb4-rlRCFyT_B5N.300x300.jpg)
文字稿 🔗
Akash Kshirsagar: welcome to All Core Dives Execution number two forty seven. Today's October eighth. and we have successfully undergone Lamsterdam fork on the Sopolia test net, which is exciting. Good job, everybody. does do the pandas wanna give a An update there? It was a boring fork. Yeah. Congrats Do you want to give the update Bambus or Yeah, it was pretty boring. Do you have anything else to add? it went pretty well, I think. I would also say. And gas limit ramped to two hundred million now, which is nice. after the fork, that went pretty well, I think. Just some clients needed to update. Great. Do we have any other any other things that we want to cover before talking about scheduling the hoodie fork? I have some stuff for mainnet shadow fork for benchmarking, but we can do that after also. regarding EPBS, I was curious if we could elaborate a little bit on maybe builder searcher participation on Sipolia. Are we seeing much? We're seeing a few builders coming online, but n nothing crazy. I'm actually a bit surprised that how little builders are participating on Spolio. we currently have five builders active. well, four, 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. and two are Sigma Prime. So really the the big players are not yet not yet on Cepolia. Right, thanks. And we are also seeing that lots of local build blocks 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 run a better force apollier, but maybe we should. I'm not sure. Great. I think that we can talk about scheduling the the hoodie 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 twenty sixth and one is Tuesday the twenty seventh. do right now I have defaulted in that in that pull request to Monday. Do clients have any preferences? about those two times. One thing I would like to raise is this is a week before DEF CON 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. Great. If no pushback, then we will schedule that for Monday the twenty sixth at seventeen forty two UTC. when do we need to get releases out for that? Tuesday does look like a lucky day. do can we say a week before that? Or is that too do we need more time than that? We would do at least ten days. Ten days. Okay. let's see if we're doing the twenty-sixth. So by next Friday then? By October sixteenth, that would be ten days. That gives the full week of the nineteenth through the twenty third for people to update their nodes. tight to get releases out by next Friday. What is what feels like the earliest POTUS? It's tight on both 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 twenty-sixth, but we have like staking pools that are that are deployed on hoodie, like all of the home stakers are deployed on hoodie. it's a much more complicated fork to to have than just a polia 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 the two weeks, we're not going to be able to put them. Right? So we we should like cut a release today or tomorrow in order to be able to be ready for hoodie. And besides anything. I really think we should have for Hoodie, 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 this these flags ready on clients. Do we not have those flags right now? Prism does not have a way of disabling the 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 Rocket Pool or Lido, then we need to cut up the release tomorrow. 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 two weeks. When do you propose we to def that? I do not know. If we do if we do fork on the twenty sixth or the twenty-seventh, 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 Cepolia? We like the majority of clients had a patch release right before the fork. Because the release that came out in the in the blog post was not the release that actually needed to be used. 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 nodes be since it's a quick operation for them and it is not such a decentralized validator set as like Holashki for example was. I think if the sixteen is fine by clients, that should give ten days. I I think ten days is more than sufficient for everyone to update. And if it's not, then they can update afterwards. We still control probably eighty, ninety percent of the value yourself easily. So it's not like we're gonna James, what docs state that we give two weeks? I'll I'll I'll need to find it, but that's that's from memory. I th I thought it was written down somewhere. It was two weeks. Okay. I can't I the only two weeks that's in my head
Load full transcript
is the two weeks between between test nets, but I can't Yeah, I'm not sure. for now, can we say client releases by the sixteenth? That gives ten days for for operators to upgrade and that is eight days from now. Is that too tight for clients to cut releases? Ivan. yes, I I'll I'd like to try to move from Monday to Tuesday. most of the Etherex team will be flying on between twenty sixth and twenty seventh. We are making a couple of short days to Europe because to to avoid a plus thirty five hours flight to India, so i i in that day we'll be flying. Maybe if we can do it Tuesday, we'll be better. Yeah, but this argument is also to a bunch of other people that will be flying on Tuesday to Wednesday. So yeah, the question is there whether would there would be more people flying on Monday or whether there would Can y'all Can y'all put in the chat whether you guys would be flying towards the 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. Okay, fair. That's fair. Any Chiman. 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 that the Tuesday slot is significantly later than than the Monday slot. the Tuesday slot is Like eight PM U T C and the other one is eleven U T C. 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 confr 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 hoodie and mainnet then we are planning the the gas limit change on the forky puck. okay. Anything else, Glamstrom? I think Stefan, did you have one more thing that you wanted to say? yeah. so basically I did the mainland 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 lowering the gas limit amount. and we also went through the gloss 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 bars, and that's probably a good edge case to test with very very large payloads. but I'm planning on relaunching the benchmarking shadow fork. So this Meta Shadow Fork One 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. Great. Thank you. Do we have anything else on Glamstram? All right, almost done with this work. then we will move on to Hagota. and the first thing I wanted to go through with Hagota 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. Hey, good morning everyone. Can you hear me all right? Yes. Okay, perfect. Seems like the monthly laptop boot worked for the audio. Okay, can you see my screen? Yep, looks good. And I'll just share the link to the slides and this site that I created in in the chat. So thanks, Nixer. 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 and whether that data sort of gives us any signal that could help with scoping. 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 this EIP, but scoped to the execution layer. And this has only existed since Amsterdam, where Mario created this template with 24 questions or criteria. And you can give a score from zero to 72 to some EIP that you get as input. And we did this for Amsterdam. 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 an example in the bottom right-hand corner. So that basically this is a quite simple example. did we add in, did the CIP 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. It seemed that the first version of the template had a few pitfalls and it, for example, it didn't really take into account like a cross-EIP interaction very well. And Mario did like a sort of retrospective like evaluation of what the Amsterdam 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 it captures cross EIP interaction as well. And like Mario and I were were talking about this and like wondering if it's like actually useful. I mean, who knows? Like with 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 the IPs 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 like last night and I reran it with Opus 5.5. and it's ran like so the it bay claude claude were basically like evaluate an EIP and for the retrospective assessments, it tries to I've picked dates from the EIP's markdown and and commit refs, which represent when like fork development started or scoping stopped and took a snapshot of 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 it's somehow sandboxed. It's not perfect, but it will have been trained on that data, but it is what it is. and when I've I did this study like six weeks ago with like Sol 5.6 or something, and and it seemed to over evaluate a lot of things and it seemed to get things really blatantly wrong. So I just I've I've made a proposal to improve the template again, but it keeps the criteria, so it shouldn't really change what a human writes, 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 It's just basically trying to keep the wording a bit more a bit more precise to avoid disambiguity for for the 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 main that? And you can see that 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 like 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 colour 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 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 CIP interactions by things that forgot to get specified from security and performance, in particular for the benchmarking effort and gas repricing for Amsterdam. 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 pre-compile, 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 ERPs, there's a there's a lot of information here. And it it's just to you know give, I think it's it's 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 t 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. Like Accumulated. And then on the y-axis, what you see is the time from the first two execution layer client dev net until mainnet, how many days that was. And yeah, I mean, doing a least quest 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 and remove or add EIPs, 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. Before we would CFI any of the other PFI EIPs. That's pretty much it. I'd I would just like to say one more thing, and that's more of more of an outlook about this work. So all these numbers, are we optimizing like for the for the 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, unspecified aspects, inconsistencies between a required EIP and the EIP being studied, and help provide tooling to EIP authors in order to then improve their specs, which will then improve and help people's lives implementing respectively agents' lives and implementing respects. All right, that's about me. Thank you very much. Thanks very much, Dan. Mark? Yeah, did you have it look at actually implementing these EIPs? Cause like for example, EIP seven five four nine was like in Electra where we changed the attestation and from a spec point of view is quite simple, but from an implementation point of view is quite difficult. So like are you are we including just the time there as well to actually, you know, put this in clients. I think it's a fair question. And I mean, throughout this study, I asked myself lots of questions like, what am I doing with my life? Like, is this worthwhile? And at the end of the day, the LLM is 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 We could think about that as things get better and better. what I can say is today that the specs team on the EL side has implemented, or they've got PLs up for every CFI 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 how how good the match is. So you can find some human scores like on the side, but they're that you can't really compare it one to one because they're on an older version of the spec. I 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. So I I see where you're getting at. And I think that the probably the most important thing would be to have a dashboard which shows whether the spec is worth implementing yet. So I 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 micbound spec to validate it so not necessarily to get a number but to get the fact that that this line in the 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 that some Downstream EIP stays consistent with its its dependent EIP. So for example, with frames and keep nonces, the key nonces EIP, if something changes in 8141, we get feedback immediately that the the dependent EIPs need updating and that you know if someone forgot to do it, for example. I 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. Great. does anybody else have any comments on that? I think that this is a really useful place to to start out to make sure that their stomachs aren't bigger than our whatever the phrase is, so that we don't overscope this fork. because we do have a lot of VIPs still to scope. with that, we will move on to the next agenda point. I wanted to give two or three minutes to Lukash, who wanted to talk about actually speeding up and better parallelising these works. Thank you. one comment about the tool. I like the tool. I think it's probably can be iterated upon and and made better even if it's already useful today. And I agree that's actually giving AA LLMs EAPs to prototype, not only to look at the spec bull, 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 Nevermind, we are currently implementing EIPs as soon as they get CFI'd. We already have 150 PRs related to Hagota. 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 Bantec initiative to standardize tracing, which I think should be looked upon and studied by by more people how it works. I can 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 EAPs, 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 AP, 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 LM already opens a PR with a fix for the client team to look at. That's very easy thing to do. and if we have a good dashboards 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 L LMs and AI. I think the the 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 nevermind. 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 EAP 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 in this kind of tools if I have a good idea how to what is needed. that's it. Thank you, Lukash. before I move on to Mark and Justin, I'm just gonna say I'm gonna time box 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. Yeah,
I kinda just also wanna echo the sentiment because like I I can remember back in the electrifork scheduling. When we were considering Mac C B, like at the time, just due to the resources that we had, we basically had one client Prism 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 at least at first it was just POTUS who had had like any kind of handle on how complex Mac C B would be. And then so we kind of went with that because it was all we had. And then later we kind of reassess that and that's how Maxi B 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 way like at least initially spec'd and through implementation, even if it's AI slop, and then rate it 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. Justin? Maybe. You're muted, Justin. Great. All right, 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 w 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 I I would like us to be specific about this. And follow-up point to that is like. Lucas, I liked your write up. It was very good. The idea of kind of just going towards four 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 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 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. Luis. yeah, I wanted to raise a point about the specs and and the use of AI writing specs. I think w we need to be like specific, co simple and concise on 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 specifications so which allows us to improve and and make the best version of the the EIP Yeah, I I would like like to hear like how we how do we solve this problem and what's your thoughts about that. 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 on the all the all its edge cases. So we don't want diversity of spec because those are consensus issues. just to to follow up on your point, Justin. PQ, for instance, I don't think is an easy thing to accelerate with AI. maybe in terms of implementation and how it works. but I think the main bottleneck the bottleneck there is decision making and we can't really do that with AI. I 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 that's not a thing that we let AI do, and I'm not sure that we should. Yeah, but there's a lot of admin and there's a lot of stuff that can be automated around it. That's Yeah, that could accelerate it. But yeah, the the the decision making we we still have to do. Mark and then let's let this be the last comment. 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 div 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 a an initial vibe coded spec and vibe coded implementation is fine for like an initial score and an initial assessment because the alternative is nothing because we don't have the resources to vibe or to to 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. 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 doping. 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 a new EIP that he'd like to talk about adding to the PFI list. yeah. So this we already did half of this, the original in Gramstem, 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 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 I would like us to reconsider, not necessarily, you know, CFI it for the fork, but reconsider the metering based on contract size. 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. Okay. then we'll move on to the eleven EIPs that need decisions. I'll share my screen. Make sure I choose the right screen. I can you guys see my screen? Yes, yes, yes. okay. I'm gonna put the chat in it too, so that Live stream 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 a 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 sub in support just saying it's something that we would like, but we're not sure that it's urgent. I am just So for fifty nine twenty, this is the the last one that we had that was the highest rated. are we okay CFI ing this one? Is there any push for DFIing it based on keeping the the scope smaller? zoom in. Okay. Ben? I'm keeping the the scope smaller. I mean it's not it's not an SFI, so I don't think there's a problem. We can always we can always do another round where we we DFI based on okay. I'm gonna move to CFI fifty nine twenty then. and then we can move on to eighty-one fifty-one. So easy recover. this got a pretty good rating from all the clients except for Aragon and Rhett. does anybody want to say anything on on this one? Yeah, this should be paired directly with set code from 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. Okay, great. Do they want to say anything about those ones? I can go bit for BESU. We discussed this a little bit further. We are more open to it, but not enough to actually change it to to be. 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 we care more about as well. So I I treat treat us as a C plus. Great. is this Can I just ask like what sorry, hello. what what's your what is basic preferred approach for EOAs to migrate to post quantum? I don't have an answer to that right off the top of my head. because to me, like setcode from 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 h so highly is important. But if you guys have an alternative approach to prefer it, like we could discuss that. I just think that like we need to figure out in Hagota
how EOAs can become post quantum. And if it's not this, then we should decide that. 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 I I don't I don't think I'm prepared to answer that question. we we 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 we also have trouble teasing out the size and complexity that comes with some of these ratings as well. Carlos, do you still have your hand raised? never mind. like client make the point, so that's it, yeah. Okay. so as as I understand this is some Some path to PQ readiness is is dependent on this. and so CFIing it would create that path, whereas n DFIing it leaves no path. Yeah, let me clarify Basie's position here. We don't wanna be a blocker on this. This is this is kind of our our you know our our ranking of it amongst everything else. So like if everybody else thinks that this should go in, we're certainly not gonna put up a fight. Cool. since these go together then are we comfortable see if buying both of these? That's eighty one fifty one and eighty two ninety eight. 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. Milosh, who agreed to champion this, who unfortunately could not be at the call today, gave an update on T Create. and I think that there was pretty good response seeing that this was something that that is being introduced in Glamsterdam and doesn't have a doesn't have a this this fixes something that isn't being introduced in 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 eighty three sixty were Etherex, geth, and reth. Do do they wanna weigh in at all? Because otherwise this is quite highly rated. on the ether side, sorry Nix, so I couldn't give you my opinion in time. we are okay for tearing it up to a B. I I was thinking between a C and a B, but I I'm I'm okay on doing it. I'll do it I would start thinking on doing it later in the process after we figure out all the main ones, the main EIPs. Okay, yeah, that's That makes sense then. 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 DFIing unless there is opposition. The next ones I think are seven seven seven seven nine eight eighty seven seven eighty seventy seven and seven six six six. These are ones that have flags on them or have been flagged as not urgent by clients. So let's start with seventy seventy seven nine. Does anybody feel like this is urgent? and that we have to get this in given the the scope that we're already looking at for Hagoda? yeah, so I recently looked at sort of a light client working off bowels as the data. And block hash 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 block hash, so you're reading from the storage, then that will be in the bowel. and and also in the data. So you won't need the trailing two hundred for six headers. So I'd I'd like to move Nethermind's vote up from B to to A. Ignatio. yeah, as an EIB champion, I I agree with what Ben said. It was kind of the the underlying purpose of proposing this for Heota. I particularly asked Dragon from Redh, 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 Red is here can give it's a view about this if it is like a strong DFI or they don't really care about it. All right. And we can move to CFIing this one as well. any opposition there? Okay. then eighty seventy seven. this was really mixed support. I I'm gonna ask if anybody Chava. I let you ask the question. if anybody opp 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. Yeah, so why I think it's important. We are making networking changes on the on the C L. but on the EL, we have the Mampool. And the two visions of how the transaction volume that we are increasing should should get on chain. And one is builders anyway have the private feeds. And the other is through the Mampool. And this is to support the Mampool vision in which we are increasing the capacity of the Mampool. And the underlying reasoning is that we should increase improve the networking of the mempool as well. And yeah, it's outlined in the in the IP with specific reasons there are. I was naming four. but in in general, with the current MEM pool, everything is fine if if we have all the bandwidths on us, or all the bandwidths that we need. but we are absolutely not prepared to operate in a regime when we have a node which is which is falling back. so this is this is to to make that work. Since we are raising the gas limit already now and we don't know what we will do in Hagota, 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. Lukash. so two 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 your 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 EAP, exactly this one, like four 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. It does it has a real good chance of of going into our pool 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 announces is not enough there. Okay, I I I see. So send announce is is enough for for many things. It it doesn't have the fees. The fees is is something we have been discussing along the CIP and as I understand you also looked at it previously. I'm absolutely open to to look into that. also others are are happy to look into that. So it it came up in in in many other discussions that the fees might might make sense, obviously depending on transaction size and and everything. There's a size where you just send a transaction. 'cause it's almost the same, but yeah, we can we can definitely kind of make it more sophisticated in in that sense. sometimes there is a feel of that sophistication. So you know we have to work on it a little bit. But happy to work with you. 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? Yes. They don't understand your kind of decision process, but other than that, no. So I would I would add a CFI or if If it would be me. Lukash does does Nethermind want to move its its ranking at all based on the the conversation? If we if we made it more robust, I could give it a B. Which is fine and f potentially fine in fork for us. Do any other clients want to weigh in? 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 Ray. Okay. Then we will move to CFI that one. Yeah, also with frames, potentially putting transactions in the mempool costs a lot more. So It might be interesting from that respect. 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. the next one we have on the Docker is seven six six six. this got A's from Basu and Etherex and C's or D's from all other clients. Does anybody want to say anything about this one? I could also revise it to B. I actually found one edge case where where this pre compile I had to optimize around it. So making it removing it kind of way would also solve this, so it is a bit of technical depth. 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. Any other comments around this one? yeah, I assume I assume there's still an appetite to, if feasible, move more pre compiles in the future to EVM. So this would be like a useful as as you said, Justin, to to prove that mechanism in a very low risk way. Felix. So I'm somewhat strongly against this EEEP. the main reason is that I think like we can we can talk about Eva E VMifying pre compiles that actually do something, but this one is not I mean, it's just trivial thing. So it doesn't really make sense to like spend resources on Like this that's why that's why it's low risk. I mean that it low risk in the sense that like I'm it 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 kinda pointless. It's better to talk about the other ones where we're trying to reprice the pre compiles based on their EVM code, but for this one it's it's a bit it's more this I feel this is more signaling EP than actual technical implementation EP. what does that what does that mean? Like I mean as it 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 well we if we're gonna use the EVM to implement something that used to be a pre compile, we should do a real one, like a pre compile that is actually you know does something. 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 pre compile. I mean the general benefit of changing the the a precompiling to EVM code is that it de risks it. So it is kind of a low risk operation. As long as you yeah. 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 EP shipping. So there's no r risk in running the EVM instead of a pre-compile 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 pre-compile into a something else. I mean I think there's technical risk to changing a pre-compile 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 free compilers 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. There's no risk in that. Like on the implementation level. Do you
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. yeah, I'm just reading our comments. Yeah, I don't think we should spend too much time on this. U. I agree that implementing it would be faster than defying. All right. Let's let's move this one to CFI and we can I I do want to point out that there is another part in this process that we added. We talked about it in Smallbard, which is prioritizing the CFI DIPs 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 CO the other CFIs as time goes. Thank you guys. Wait, why are we not DFIing it? 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. Jochem has a point on potentially changing the gas cost, which is breaking potentially breaking compatibility, if the I understand it correctly. Yeah, so two points. The EIP says in the security considerations that the the as no new f 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 what is also not in the EIP is if this contract then gets removed from the default WARM accounts. So this at least needs needs to get some attention on the spec side. Okay, I would then D F high it because it's not worth it. Yeah, I mean this this thing copies memory from A to B. Like why are we messing with this? Like Okay. Then moving to DFI. Guys give me one one DFI. Take it. Okay. moving on. The other the last three I think are 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? 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. 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 CFIing 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 CFIing 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. You know. So a couple of questions there. the 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 to directly address Kevin'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 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 bases 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 gonna 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 RagMD. Nobody's using those. Look at you know BLS, you know nobody's using those is relatively low impact. But I think that's the wrong comparison. What we need to look at is P two fifty six. And that has been brought around that has been Brought up over eight to ten years before it was finally adopted in various levels of various people. The reason it was brought up is because it's the one the 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 Hegatop, but instead to reserve one of the 100 series pre-compile 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. that'll avoid the problem we have P256, which is where there are about two or three different definitions. there are different reactions to the various you know, how you how do you respond when the answer is no, do you respond with a hash? Do you not respond with the hash? the standardization, putting it in like the 100 series makes it lot easier to, if the if may Ethereum decides suddenly it does need it later, to just turn it on. It also creates space. or for roll ups and L2s to decide, well, even though Mainnots mainnet doesn't like lattices, we like lattices because our customers like lattices. So we're gonna 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 map behind it, we need to make room for all users to use the whole of Ethereum. Antonio. Right. yeah, I mean probably people know already my opinion, and as you probably know, we have been running biweekly breakout rooms on on this topic. We have been looking at the beginning at at lattice, 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 some testnet called the sugi. where we actually are running at the moment a version of Sphinx with the 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 the with this with this EIP is the fact that it's really short sighted. Namely like there is no plan to scale this. if l literally every user of Ethereum is gonna use this this pre compile, the the the 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 ZKAVM compatibility. we are the the the moment is I mean the gas is really mispriced at the moment. If we we keep in consideration the the the the the the the fact that we're gonna move to ZK VM, this is gonna be really a total bad price at the moment. And and the the the the last but not least, I I mean I've I 10 other reasons, but I don't want to take all the evening. is basically like we are introducing this this this new assumption in Ethereum at really bad timing. we have seen what happened in the last weeks, months, introducing this this right now. I don't know if it's the best things. one once we have a solution that actually works and is is is really scalable with hash and it's really conservative. And I stop here for now. I can answer some questions more offline. Thank you, guys. it seems like a 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. All right, eight one one six replace cumulative receipt fees fields. low ratings from Besu, Etherex, RETH, mid tier Aragon, and supported by Geth and Nethermind. Does anybody want to say anything about this one? Then 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 it's yeah, it it's technical debt removal. And also network bound. What is the complexity of this one? Very low. Ethernet or Baser, do you guys want to say anything? You guys rate it or ref? we agree with Ben's and Lucas'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. Yeah, we don't see it as a priority. So we just deified it. We don't see any Okay. Great. I think this is an easy CFI, but put at the bottom of the priority list item then. We'd be fine with that. I I'm not sure if it was proposed this time, but I'd I'd like log removing the logs or to me seems like a more important one. Sorry, not the logs, the bloom filter. Bloom filters, yeah, and we rated that one higher as well. yeah, that's
CFI. So okay, we can Put that one above that then. All right, we've got one more to consider today and then 7907 to next week. do we want to use the last eight minutes to get a decision on persist warm access sets across reverts? looks like Etherex felt strongly against it, RETH and Aragon were mildly against it, and the rest was lukewarm support. Interesting that it's authored by Durgan and only a C tier from Ruth. I have a bit of AT thirty seven PTSD and this this feels like revisiting that wound. YX. So I just want to give some context on our decision here to put it in A tier. So we did analyze this EP 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 other 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 to see is is is it correct or not or what are the implications. Does anybody want to sway either direction here? CFI, DFI. It seems lukewarm support and given that we already have a a ton in the in the fork, I I would lean towards DFIing. I I'd lean that way 'cause it's changing it's making n what it's changing is quite deep out of fork boundary. I don't know. I don't know if it's worth it. 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 gonna have the whole next call to talk about 7907 and whatever other Hagodoscoping 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 Codup added, which was just sort of pressing on Justin Drake's Bunker mode tweet yesterday. Does Andrew wanna say anything about that? I think the idea was Pay I don't know, paying attention to that in terms of pagoda scoping. if there's nothing else today then I think we can close up. if I may take thirty 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 Cipolia test net. 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 enterprise to collect the feedback. Great. Thank you, Pooja. Yes, scoping was definitely fast. I'm gonna contribute a lot of that to Fort Cast and Mark's work. Thank you guys.